hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dian Fu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11335) KMS ACL in meta data or database
Date Tue, 27 Jan 2015 07:32:35 GMT

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

View raw message