[
https://issues.apache.org/jira/browse/HADOOP-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16422633#comment-16422633
]
Larry McCay commented on HADOOP-15325:
--------------------------------------
I am admittedly sort of close to this implementation and have been trying to
keep my feelings in check as the fundamental premise that we should stop
putting credentials in config is certainly valid. However, as
[[email protected]] points out consumers of this API are at different places
in their migration.
I feel like it should be handled as a deployment consideration rather than the
removal of a feature.
Warnings of a Best Practice Violation could certainly be logged.
In other words, a list of properties could be configured that can be put
directly into config could result in fallback being enabled for those
properties only.
I made a more detailed description of what that would be like in the other JIRA.
> Make Configuration#getPasswordFromCredentialsProvider() a public API
> --------------------------------------------------------------------
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
