[
https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212513#comment-15212513
]
Larry McCay commented on HADOOP-12942:
--------------------------------------
bq. They aren't - but they never were assured of this in the first place.
They were assured of the default password always being available.
If we are going to define the best practice as using the password-in-a-file
approach then it should be documented clearly that this config setting needs to
be in place otherwise the default will be used.
bq. There is a higher probability of that with my patch, yes. I believe this to
be better than setting the user up for unintentional insecure storage of
secrets. I don't know how to handle this better, and I'm not sure that we can
since we don't know how the cred store will be accessed in the future.
Not if we warn them AND allow them to be protected from it with a -strict flag.
bq. See if I agreed with this I never would have filed this jira. I feel that
it is a bug to give the user the impression that a value is being securely
stored when in fact it is not. Hardcoded "none" provides no protection.
I can agree that the non-obvious aspect of this JIRA is a bug.
A hardcoded password actually provides more protection than that afforded to
the password-in-the-file itself.
It will only be protected by file permissions.
Printing a warning, documenting it clearly and providing a -strict switch would
satisfy the non-obviousness bug.
If we didn't have this existing pattern of referencing password-files and had a
way to connect all the dots for the password that we get through the prompt
then this would be perfect. Unfortunately, I think that prompting like this
adds unnecessary complexity in order to add a password that we know isn't
provisioned in the config and will likely lead to a failure at runtime rather
than provisioning time. I believe that we want to fail early.
I should clearly state that I don't think that the password-in-a-file actually
makes security much better but I can appreciate the idea of using it. But we
really are just moving the problem around until we have a credential server.
We are talking about protecting an encoded credential store which is protected
with file permissions with a password that is stored in clear text in a file
that is protected with file permissions. Add, to that, the complexity of
ensuring that file is configured properly in all environments and it becomes an
availability problem.
My preference is to try and clearly define a best practice until we have a
credential server that uses existing functionality and makes it very clear that
a default password is being used otherwise.
> 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
> Assignee: Mike Yoder
> Attachments: HADOOP-12942.001.patch
>
>
> 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)
