[
https://issues.apache.org/jira/browse/HADOOP-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated HADOOP-10433:
----------------------------------------
Attachment: HADOOP-10433.patch
patch fixing the 'chiper' typo
Larry, trying to answer your comments/concerns:
The {{get key versions : GET
http://HOST:PORT/kms/v1/key/<version-name>/versions}} was a typo in my comments
and in the code, it should have been get key versions : GET
http://HOST:PORT/kms/v1/key/<key-name>/versions
The problem with using {{GET
http://HOST:PORT/kms/v1/keys/<key-name>/<version-name>}} to get a version is
that we are assuming the implementation first looks for the <key-name> and then
for the <version-name>. The implementation could have direct look ups using the
<version-name>. If that is the case, then the implementation would have then to
do an additional lookup to verify that the specified <key-name> matches with
the <version-name> given. In your example
{{http://HOST:PORT/kms/v1/keys/1234/1234}}, if the version-name (the second
1234) is globally unique, then asking for
{{http://HOST:PORT/kms/v1/keys/abcd/1234}} should give an error, thus it would
require an additional lookup in the implementation.
Also, I think we should make sure that the version-name is opaque and that it’s
construction (<key-name>@<version-count>) is not part of the public API. As you
indicated there are system that use UUIDs as the version. It may barbaric, but
that is how things are and we should make sure we can work with those. I don’t
think we should change the JavaKeyStoreProvider to use UUIDs, it can continue
using <key-name>@<version-count>. We just have to make sure that impls can use
an opaque value as <version-name>. I’ll verify how things are and open a JIRA
if necessary to follow up with this.
Does it make sense?
> Key Management Server based on KeyProvider API
> ----------------------------------------------
>
> Key: HADOOP-10433
> URL: https://issues.apache.org/jira/browse/HADOOP-10433
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 3.0.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: HADOOP-10433.patch, HADOOP-10433.patch,
> HADOOP-10433.patch, HADOOP-10433.patch, HADOOP-10433.patch,
> HADOOP-10433.patch, HADOOP-10433.patch, HADOOP-10433.patch,
> HadoopKMSDocsv2.pdf, KMS-doc.pdf
>
>
> (from HDFS-6134 proposal)
> Hadoop KMS is the gateway, for Hadoop and Hadoop clients, to the underlying
> KMS. It provides an interface that works with existing Hadoop security
> components (authenticatication, confidentiality).
> Hadoop KMS will be implemented leveraging the work being done in HADOOP-10141
> and HADOOP-10177.
> Hadoop KMS will provide an additional implementation of the Hadoop
> KeyProvider class. This implementation will be a client-server implementation.
> The client-server protocol will be secure:
> * Kerberos HTTP SPNEGO (authentication)
> * HTTPS for transport (confidentiality and integrity)
> * Hadoop ACLs (authorization)
> The Hadoop KMS implementation will not provide additional ACL to access
> encrypted files. For sophisticated access control requirements, HDFS ACLs
> (HDFS-4685) should be used.
> Basic key administration will be supported by the Hadoop KMS via the, already
> available, Hadoop KeyShell command line tool
> There are minor changes that must be done in Hadoop KeyProvider functionality:
> The KeyProvider contract, and the existing implementations, must be
> thread-safe
> KeyProvider API should have an API to generate the key material internally
> JavaKeyStoreProvider should use, if present, a password provided via
> configuration
> KeyProvider Option and Metadata should include a label (for easier
> cross-referencing)
> To avoid overloading the underlying KeyProvider implementation, the Hadoop
> KMS will cache keys using a TTL policy.
> Scalability and High Availability of the Hadoop KMS can achieved by running
> multiple instances behind a VIP/Load-Balancer. For High Availability, the
> underlying KeyProvider implementation used by the Hadoop KMS must be High
> Available.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
