[
https://issues.apache.org/jira/browse/HADOOP-11335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293114#comment-14293114
]
Dian Fu commented on HADOOP-11335:
----------------------------------
Major changes in this patch: Remove class KeyProviderAuthorizationExtension and
move all its functionality to KeyProviderCryptoExtension.
Thanks [~asuresh] for the suggestions about the re-design. I found some of the
ideas you proposed are difficult to implement, could you help to see if the
issues described below make sense?
* Metadata
You suggest to use a extension of {{Metadata}} to support ACL, such as use
{{MetadataWithAcl}} and use templatized {{KeyProvider}} such as {{pubic class
KeyProvider<M extends Metadata>}}. I really like this idea but I encountered
some difficulties in implementation. The difficulties are:
Let’s image such implementation: {{public class JavaKeyStoreProvider extends
KeyProvider<Metadata>}} and {{public class KeyProviderCryptoExtension extends
KeyProvider<MetadataWithAcl>}}. If user create a ACL via the methods of
{{KeyProviderCryptoExtension}}, an instance of {{MetadataWithACL}} will be
serialized and stored into backend storage. Then user roll a new version of the
key via the methods of {{JavaKeyStoreProvider}}, the metadata of the key will
be firstly deserialized to instance of {{Metadata}} and is then serialized to
the backend storage. This will cause problems. As the instance of
{{MetadataWithACL}} is changed to {{Metadata}}. In my opinion, generic is
unsuitable for this use case. Any thoughts?
* KeyACLs
You suggest to use the {{KeyAuthorizationKeyProvider.KeyACLs}} interface to
implement the different ACL providers. It’s a good idea, while I found the
following two reasons which prevent me to do so, I’m not sure if these reasons
make sense to you:
*# This interface not only considers key acl, but also other acls such as
default key acl, white list key acl, etc. But in our design, we only consider
supporting different key ACL. For default key acl and whitelist key acl, we
still use configuration.
*# This interface is used by KMS, which means that user can only access ACL
through KMS. But we also want to make ACL can be accessible without KMS,
although this is not a requirement in product environment. This is a code level
requirement. As we know that in KeyShell, it use {{keyProvider}} to communicate
the backend keystore. {{KeyProvider}} can be any implementations such as
{{JavaKeyStoreKeyProvider}}, {{KMSClientProvider}} or others implementations.
If we use {{KeyAuthorizationKeyProvider.KeyACLs}} interface to implement
different ACL providers, then how to deal with the case when a
{{JavaKeyStoreKeyProvider}} is used?
> 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, 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)
