[
https://issues.apache.org/jira/browse/HADOOP-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16414715#comment-16414715
]
Larry McCay commented on HADOOP-15325:
--------------------------------------
[~shv] - It took me a few mins to understand your perspective.
I think that you are viewing the use of getPassword as a mechanism only to be
used for old passwords that used to be stored in configuration and that any new
ones should use the credential provider API directly instead.
My view was that Configuration.getPassword is a nice convenient utility for
accessing passwords that may be stored physically in the config file or
elsewhere securely via credential provider API.
I think both perspectives are probably valid but it seems somewhat unreasonable
to make code that may already be acquiring passwords through getPassword use a
different mechanism just because the passwords are newer and don't need
backward compatibility.
I can see a list of property names that allow clear text storage for backward
compatibility or other reasons being an easy way to:
* limit newer properties to only secure storage
* allow new deployments rather than upgrades to turn off clear text storage
completely
* migrate to no clear text over time
Codifying this deployment specific behavior to make the decisions for them
seems too inflexible.
Considering that we already have a configurable fallback behavior, extending
this to treat some properties differently from a deployment consideration seems
to make sense to me and would allow you to achieve exactly the behavior that
you describe without making the decision for others.
{code}
/**
* @see
* <a href="\{@docRoot}/../hadoop-project-dist/hadoop-common/core-default.xml">
* core-default.xml</a>
*/
public static final String HADOOP_SECURITY_CREDENTIAL_CLEAR_TEXT_FALLBACK =
"hadoop.security.credential.clear-text-fallback";
public static final boolean
HADOOP_SECURITY_CREDENTIAL_CLEAR_TEXT_FALLBACK_DEFAULT = true;
{code}
The above is used in the getPasswordFromConfig method:
{code}
/**
* Fallback to clear text passwords in configuration.
* @param name
* @return clear text password or null
*/
protected char[] getPasswordFromConfig(String name) {
char[] pass = null;
if (getBoolean(CredentialProvider.CLEAR_TEXT_FALLBACK,
CommonConfigurationKeysPublic.HADOOP_SECURITY_CREDENTIAL_CLEAR_TEXT_FALLBACK_DEFAULT))
{
String passStr = get(name);
if (passStr != null) {
pass = passStr.toCharArray();
}
}
return pass;
}
{code}
Check a property name list after the overall fallback enabled check and you are
good to go.
We may want to have some special values like ALL|NONE and also allow for a list
of property names that don't allow fallback.
Default to ALL for current behavior. Very strict environments can set it to
NONE and others can choose the new properties vs old properties approach or
whatever they like.
> Add an option to make Configuration.getPassword() not to fallback to read
> passwords from configuration.
> -------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-15325
> URL: https://issues.apache.org/jira/browse/HADOOP-15325
> Project: Hadoop Common
> Issue Type: Improvement
> Components: conf
> Affects Versions: 2.6.0
> Reporter: Wei-Chiu Chuang
> Assignee: Zsolt Venczel
> Priority: Major
>
> HADOOP-10607 added a public API Configuration.getPassword() which reads
> passwords from credential provider and then falls back to reading from
> configuration if one is not available.
> This API has been used throughout Hadoop codebase and downstream
> applications. It is understandable for old password configuration keys to
> fallback to configuration to maintain backward compatibility. But for new
> configuration passwords that don't have legacy, there should be an option to
> _not_ fallback, because storing passwords in configuration is considered a
> bad security practice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
