Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 18 Feb 2017 00:22:44 +0000 (UTC)
From: "Larry McCay (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.13029353.1482210822000.1122.1487377364206@Atlassian.JIRA>
In-Reply-To: <JIRA.13029353.1482210822000@Atlassian.JIRA>
References: <JIRA.13029353.1482210822000@Atlassian.JIRA> <JIRA.13029353.1482210822773@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HADOOP-13923) Allow changing password on
 JavaKeyStoreProvider generated keystores
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 18 Feb 2017 00:22:51 -0000


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

Larry McCay commented on HADOOP-13923:
--------------------------------------

In general, I agree that it is not worth the trouble to add the change password API.
I don't exactly agree on the following statements through.

bq. Idea on adding a move functionality to migrate keyprovider works, and I like that idea.  But feels this is a parallel feature. From admin's POV, changing a keystore password would then require to: setup a new keyprovider service, migrate, change all client configs to point to the new keyprovider.

You don't have to change client configs if you just rename the keystore. :)

bq. I think we can document hard that jksp isn't supposed to be used anywhere outside of dev/poc, to discourage its use... and use this patch to let who's running on jksp change there password to something other than the default 'none'.

I disagree here. It is perfectly legitimate to use a java keystore provider but folks should be aware of the details of doing so.
Just as in the use of the same for the Credential Provider API, the keystore password is only a formality of persistence. The actual protection of the key is in the proper use of file permissions. I wouldn't be opposed to describing the use of KMS as a stronger option and describe why this is so in a similar set of docs.

The following documentation attempts to communicate these details with enough fidelity to make an informed decision for credential provider approaches: http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/CredentialProviderAPI.html#Credential_Management

See the provider types and then the keystore management sections.

Pursuing proper Key Provider API documentation is certainly worth doing.

> Allow changing password on JavaKeyStoreProvider generated keystores 
> --------------------------------------------------------------------
>
>                 Key: HADOOP-13923
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13923
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: kms
>    Affects Versions: 2.6.0
>            Reporter: Xiao Chen
>            Assignee: Xiao Chen
>         Attachments: HADOOP-13923.01.patch
>
>
> {{JavaKeyStoreProvider}} generates a jceks keystore file for key storage. Although we have different fall backs in {{ProviderUtils#locatePassword}} to specify the keystore password, it appears the password itself can never be changed after generation.
> This jira is to make it possible to change the keystore password.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org