Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Fri, 25 Apr 2014 23:17:16 +0000 (UTC)
From: "Alejandro Abdelnur (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12703400.1395728104576.185059.1398467836673@arcas>
In-Reply-To: <JIRA.12703400.1395728104576@arcas>
References: <JIRA.12703400.1395728104576@arcas>
Subject: [jira] [Updated] (HADOOP-10433) Key Management Server based on
 KeyProvider API
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HADOOP-10433?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alejandro Abdelnur updated HADOOP-10433:
----------------------------------------

    Attachment: HadoopKMSDocsv2.pdf
                HADOOP-10433.patch

New patch addressing Andrew=E2=80=99s feedback.

The documentation defines the HTTP REST API (attaching PDF of it for easier=
 review)

The ACLs have been changed to be able to discriminate per KeyProvider opera=
tion.

BTW, the audits logs in the KMSServer are done at the end of every method, =
once we know the method is successful, for failures, the KMSAuthenticationF=
ilter will audit all failures.

On the comment not using Hadoop ACLs, I would prefer using it and then impr=
ove it (in a diff JIRA) to suppport ":" as separator.

> 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, HadoopKMSDocsv2.pdf, KMS-doc.pdf
>
>
> (from HDFS-6134 proposal)
> Hadoop KMS is the gateway, for Hadoop and Hadoop clients, to the underlyi=
ng KMS. It provides an interface that works with existing Hadoop security c=
omponents (authenticatication, confidentiality).
> Hadoop KMS will be implemented leveraging the work being done in HADOOP-1=
0141 and HADOOP-10177.
> Hadoop KMS will provide an additional implementation of the Hadoop KeyPro=
vider 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 e=
ncrypted files. For sophisticated access control requirements, HDFS ACLs (H=
DFS-4685) should be used.
> Basic key administration will be supported by the Hadoop KMS via the, alr=
eady available, Hadoop KeyShell command line tool
> There are minor changes that must be done in Hadoop KeyProvider functiona=
lity:
> The KeyProvider contract, and the existing implementations, must be threa=
d-safe
> KeyProvider API should have an API to generate the key material internall=
y
> JavaKeyStoreProvider should use, if present, a password provided via conf=
iguration
> KeyProvider Option and Metadata should include a label (for easier cross-=
referencing)
> To avoid overloading the underlying KeyProvider implementation, the Hadoo=
p KMS will cache keys using a TTL policy.
> Scalability and High Availability of the Hadoop KMS can achieved by runni=
ng multiple instances behind a VIP/Load-Balancer. For High Availability, th=
e underlying KeyProvider implementation used by the Hadoop KMS must be High=
 Available.


--
This message was sent by Atlassian JIRA
(v6.2#6252)