[
https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15207546#comment-15207546
]
Larry McCay commented on HADOOP-12942:
--------------------------------------
There are at least the following additional password files throughout the
ecosystem - I'm sure that there are probably more:
Hadoop:
hadoop-http-auth-signature-secret
hadoop.security.group.mapping.ldap.ssl.keystore.password.file
hadoop.security.group.mapping.ldap.bind.password.file
HBase JMX Remote:
HBASE_JMX_OPTS="$HBASE_JMX_OPTS
-Dcom.sun.management.jmxremote.password.file=$HBASE_HOME/conf/jmxremote.passwd"
HBase Web UIs
TLS/SSL Server Keystore File Password - Password for the server keystore file
used for encrypted web UIs.
TLS/SSL Server Keystore Key Password - Password that protects the private
key contained in the server keystore used for encrypted web UIs.
HBase REST Server
HBase REST Server TLS/SSL Server JKS Keystore File Password - The password
for the HBase REST Server JKS keystore file.
HBase REST Server TLS/SSL Server JKS Keystore Key Password - The password
that protects the private key contained in the JKS keystore used when HBase
REST Server is acting as a TLS/SSL server.
HBase Thrift Server
HBase Thrift Server over HTTP TLS/SSL Server JKS Keystore File Password - The
password for the HBase Thrift Server JKS keystore file.
HBase Thrift Server over HTTP TLS/SSL Server JKS Keystore Key Password - The
password that protects the private key contained in the JKS keystore used when
HBase Thrift Server over HTTP is acting as a TLS/SSL server.
Oozie SSL/TLS
Oozie TLS/SSL Server JKS Keystore File Password - Password for the keystore.
I'd rather not add this work to the Key and Credential provider commands.
The keystore providers are both just consumers of the same password file
pattern found else where through out hadoop.
I believe that it is generally part of the administrative platforms like Ambari
and Cloudera Manager but if you would like a CLI management tool then I think
that may add some value. Like I described it could take care of the permissions
settings, etc. Which would all be separate manual steps from the command line.
> hadoop credential commands non-obviously use password of "none"
> ---------------------------------------------------------------
>
> Key: HADOOP-12942
> URL: https://issues.apache.org/jira/browse/HADOOP-12942
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Mike Yoder
>
> The "hadoop credential create" command, when using a jceks provider, defaults
> to using the value of "none" for the password that protects the jceks file.
> This is not obvious in the command or in documentation - to users or to other
> hadoop developers - and leads to jceks files that essentially are not
> protected.
> In this example, I'm adding a credential entry with name of "foo" and a value
> specified by the password entered:
> {noformat}
> # hadoop credential create foo -provider localjceks://file/bar.jceks
> Enter password:
> Enter password again:
> foo has been successfully created.
> org.apache.hadoop.security.alias.LocalJavaKeyStoreProvider has been updated.
> {noformat}
> However, the password that protects the file bar.jceks is "none", and there
> is no obvious way to change that. The practical way of supplying the password
> at this time is something akin to
> {noformat}
> HADOOP_CREDSTORE_PASSWORD=credpass hadoop credential create --provider ...
> {noformat}
> That is, stuffing HADOOP_CREDSTORE_PASSWORD into the environment of the
> command.
> This is more than a documentation issue. I believe that the password ought to
> be _required_. We have three implementations at this point, the two
> JavaKeystore ones and the UserCredential. The latter is "transient" which
> does not make sense to use in this context. The former need some sort of
> password, and it's relatively easy to envision that any non-transient
> implementation would need a mechanism by which to protect the store that it's
> creating.
> The implementation gets interesting because the password in the
> AbstractJavaKeyStoreProvider is determined in the constructor, and changing
> it after the fact would get messy. So this probably means that the
> CredentialProviderFactory should have another factory method like the first
> that additionally takes the password, and an additional constructor exist in
> all the implementations that takes the password.
> Then we just ask for the password in getCredentialProvider() and that gets
> passed down to via the factory to the implementation. The code does have
> logic in the factory to try multiple providers, but I don't really see how
> multiple providers would be rationaly be used in the command shell context.
> This issue was brought to light when a user stored credentials for a Sqoop
> action in Oozie; upon trying to figure out where the password was coming from
> we discovered it to be the default value of "none".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
