[
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: [email protected]
For additional commands, e-mail: [email protected]
