hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13923) Allow changing password on JavaKeyStoreProvider generated keystores
Date Wed, 21 Dec 2016 18:39:58 GMT

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

Xiao Chen commented on HADOOP-13923:
------------------------------------

Thanks a lot [~lmccay] for the comment!

bq. I wonder whether we would be better served altogether to consider adding a move method
that would make a complete copy of a key into a another provider where the second JKS provider
will prompt for a new password. This could be added to the KeyShell and be able to be used
across provider types - be they builtin or custom.
Interesting idea! I think this solves the bigger problem in a more general way. I would like
to address this in a separate jira if you agree - it also solves the key migration problem.
And 'prompt for a new password' would be a new API as a part of that. (I see KeyProvider already
has a {{needsPassword}} interface, so adding a new one should be fine.)

Back to this case, the issue came up when someone wanted and already changed the *keystore*
password ({{keytool -storepasswd ...}}) and wasn't able to get the provider working - JKSProvider
only use 1 password for both the keystore and all keys. They wanted to change the *key* password
({{keytool -keypasswd ...}}) too, but ended up with the {{UnrecoverableKeyException}}. Currently
the only solution here is to not change the keystore password at all.

Feels like changing password by bring up a new KP, do the move, and shutdown the old KP is
a bit of deployment overhead for this scenario.

bq. I'm not sure that I like adding support for such a limited set of functionality of keytool
though.
Keep in mind the jceks keystore password can always be changed by the keytool. If an admin
tries to do it, currently it simply breaks JKSP - it launches ok with the new password, but
any keys with the old password won't work.

So I think this is making the JKSP more transparent actually. :) Admin knows where the key
is stored, and just wanted to change the password. It shouldn't matter which implementation
saved the keystore file.

Also, keytool comes with standard jdk, and changing keystore/key password are its standard
features. Currently the former is fine and the latter is broken because the way we handle
{{Metadata}} in hadoop JKSP, and I don't see any benefit of keeping this behavior.

So I would propose to fix this jira for JKSP, and create new jira for the move idea. Thoughts?

> 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.4#6332)

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


Mime
View raw message