You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Arun Suresh (JIRA)" <ji...@apache.org> on 2015/02/04 11:38:34 UTC
[jira] [Updated] (HADOOP-11335) KMS ACL in meta data or database
[ https://issues.apache.org/jira/browse/HADOOP-11335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arun Suresh updated HADOOP-11335:
---------------------------------
Attachment: HADOOP-11335.re-design.patch
[~dian.fu], I really do apologize for the delay.
Am posting a patch.. which is not really complete.. but I think It would help me illustrate how to use the {{KeyACLs}} interface
* I have split the {{KMSACLs}} logic into 2 parts.. one that handles the KMS level acls and the default and whitelist.. and another interface {{PerKeyAcls}} that handles key level acls.
* I was thinking that The {{PerKeyAcls}} can have multiple implementations. The default one that is configuration driven (I have a {{ConfigurationBasedPerKeyAcls}} in the patch).... Similarly, you can have a {{MetadataBasedPerKeyAcls}} that is initialized with a {{KeyProvider}} so that the ACLs can be stored within the KeyProvider metadata attributes.
With regard to the KeyProvider changes :
* I feel we should not put in Typed ACL information in the key provider itself.. the basic {{KeyProvider}} is meant for storing keys and associated metadata. I propose we store the ACLs as just another <String, String> key value based Metadata attribute.
* The create / delete ACL can thus be translated to adding / removing attributed from the Metadata.
* This also means we dont have to modify the {{KeyProvider}} / {{Metadata}} classes much.. we would limit modification to 2 methods, {{addMetadataAttribute()}} and {{deleteMetadataAttribute}}
* The CLI keytool can still expose the same commands.. but it will translate it into {{addMetadata}} and {{deleteMetadata}} method invocations.
Hope this addresses most of your concers.
Please note.. I have not flushed out some of the methods (I have left it as TODO's) to basically dicuss the design )before we move forward.
> KMS ACL in meta data or database
> --------------------------------
>
> Key: HADOOP-11335
> URL: https://issues.apache.org/jira/browse/HADOOP-11335
> Project: Hadoop Common
> Issue Type: Improvement
> Components: kms
> Affects Versions: 2.6.0
> Reporter: Jerry Chen
> Assignee: Dian Fu
> Labels: Security
> Attachments: HADOOP-11335.001.patch, HADOOP-11335.002.patch, HADOOP-11335.003.patch, HADOOP-11335.004.patch, HADOOP-11335.005.patch, HADOOP-11335.re-design.patch, KMS ACL in metadata or database.pdf
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> Currently Hadoop KMS has implemented ACL for keys and the per key ACL are stored in the configuration file kms-acls.xml.
> The management of ACL in configuration file would not be easy in enterprise usage and it is put difficulties for backup and recovery.
> It is ideal to store the ACL for keys in the key meta data similar to what file system ACL does. In this way, the backup and recovery that works on keys should work for ACL for keys too.
> On the other hand, with the ACL in meta data, the ACL of each key can be easily manipulate with API or command line tool and take effect instantly. This is very important for enterprise level access control management. This feature can be addressed by separate JIRA. While with the configuration file, these would be hard to provide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)