[
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)
