[jira] [Commented] (HADOOP-10433) Key Management Server based on KeyProvider API

["Owen O'Malley (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986936#comment-13986936 ] 

Owen O'Malley commented on HADOOP-10433:
----------------------------------------

Alejandro,
  A couple more things on the interface:
* You need to allow the user to specify the key-name when they create the key.
* Instead of throwing if the url is too long, please break the user's request into parts that fit within the 2000 byte limit.
* You never answered whether the body is xml or json (or both).
* The underscores should be on the trailing part of the url.

I'd propose it look like:
{code}
create key         : PUT    http://HOST:PORT/kms/v1/key/<key-name>
rollover key       : POST   http://HOST:PORT/kms/v1/key/<key-name>
delete key         : DELETE http://HOST:PORT/kms/v1/key/<key-name>
get metadata       : GET    http://HOST:PORT/kms/v1/key/<key-name>/_metadata
get current version: GET    http://HOST:PORT/kms/v1/key/<key-name>/_currentversion
get key versions   : GET    http://HOST:PORT/kms/v1/key/<keyname-name>/_versions
get key version    : GET    http://HOST:PORT/kms/v1/keyversion/<version-name>
get key names      : GET    http://HOST:PORT/kms/v1/keys/names
get keys metadata  : GET    http://HOST:PORT/kms/v1/keys/metadata?key=<key-name>&key=<keyname>,...
{code}

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