hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry McCay (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10607) Create an API to Separate Credentials/Password Storage from Applications
Date Sat, 31 May 2014 17:28:07 GMT

    [ 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

View raw message