[
https://issues.apache.org/jira/browse/HADOOP-10607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14014722#comment-14014722
]
Larry McCay commented on HADOOP-10607:
--------------------------------------
[~owen.omalley] I am concerned that requiring a new
ConfigurationCredentialProvider to fallback to clear text passwords doesn't
have as much value as it first seems.
It is a great way to have a meaningful default provider and would work
wonderfully when there is no configured provider path.
However, as soon as someone configures a specific provider to use, it becomes
very easy to leave the fallback provider out of the path configuration. It
would be really natural to just add the single provider to the configuration
and cumbersome to have to add two to the configured provider path. With a path
provided then the ease of the default provider is completely gone.
I've currently coded the Configuration.getPassword method to try the
CredentialProvider API and if the alias is not resolved to fallback to config.
With that in place, I'm just not sure that we need the config provider.
I guess the question is whether we want it easy to fallback to config or make
it a very explicit action to have some clear text and some not.
What do you think?
> Create an API to Separate Credentials/Password Storage from Applications
> ------------------------------------------------------------------------
>
> Key: HADOOP-10607
> URL: https://issues.apache.org/jira/browse/HADOOP-10607
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Larry McCay
> Assignee: Larry McCay
> Fix For: 3.0.0
>
> Attachments: 10607-2.patch, 10607-3.patch, 10607-4.patch,
> 10607-5.patch, 10607.patch
>
>
> As with the filesystem API, we need to provide a generic mechanism to support
> multiple credential storage mechanisms that are potentially from third
> parties.
> We need the ability to eliminate the storage of passwords and secrets in
> clear text within configuration files or within code.
> Toward that end, I propose an API that is configured using a list of URLs of
> CredentialProviders. The implementation will look for implementations using
> the ServiceLoader interface and thus support third party libraries.
> Two providers will be included in this patch. One using the credentials cache
> in MapReduce jobs and the other using Java KeyStores from either HDFS or
> local file system.
> A CredShell CLI will also be included in this patch which provides the
> ability to manage the credentials within the stores.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
