[
https://issues.apache.org/jira/browse/HADOOP-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983719#comment-13983719
]
Larry McCay commented on HADOOP-10433:
--------------------------------------
I like this much better as well.
To me, you could continue the hierarchy of the key/keyversion as well.
Additionally, I'm not sure that you need to identify the path elements with
key/keyname/version/version-name.
Each resource's path is unique unto itself and I think it holds together to
just use the values that way - as you follow the path the URI more specifically
identifies the resource.
With that in mind, I would propose adjustments along the following lines:
{code}
create key : PUT http://HOST:PORT/kms/v1/keys
rollover key : POST http://HOST:PORT/kms/v1/keys/<key-name>
delete key : DELETE http://HOST:PORT/kms/v1/keys/<key-name>
get metadata : GET http://HOST:PORT/kms/v1/keys/<key-name>/metadata
get current version: GET
http://HOST:PORT/kms/v1/keys/<key-name>/currentversion
get key version : GET
http://HOST:PORT/kms/v1/keys/<key-name>/<version-name>
get key versions : GET http://HOST:PORT/kms/v1/keys/<version-name>/versions
get key names : GET http://HOST:PORT/kms/v1/keys
get keys metadata : GET
http://HOST:PORT/kms/v1/keys/metadata?key=<key-name>&key=<keyname>,...
{code}
This flattens the hierarchy a good bit the only outlier being the get
.../keys/metadata - I think that the rest of them identify unique resources
within a hierarchy.
[~tucu00]
I'm not sure that I am grasping your concern with the 'get key version' URI and
doubt that this minor adjustments changes your feelings there. Can you
elaborate on what the issue is? Maybe provide an example?
> 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, 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)
