[ 
https://issues.apache.org/jira/browse/HADOOP-18618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684613#comment-17684613
 ] 

Steve Loughran commented on HADOOP-18618:
-----------------------------------------

+[[email protected]]

Going near JCEKS and Configuration are both big changes, so a lot of thought is 
needed here.

* What if a different engine actually wants to use a completely different 
credential provider mechanism, rather than just a path?
* If you look at s3a, it has a custom option 
"fs.s3a.security.credential.provider.path", which is evaluated after the per 
bucket settings are evaluated. But that is (a) convoluted and (b) doesn't work 
in deployments where the base credential.provider.path has been locked down. 

> Support custom property for credential provider path
> ----------------------------------------------------
>
>                 Key: HADOOP-18618
>                 URL: https://issues.apache.org/jira/browse/HADOOP-18618
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: common
>    Affects Versions: 3.1.3
>            Reporter: Surendra Singh Lilhore
>            Assignee: Surendra Singh Lilhore
>            Priority: Minor
>              Labels: pull-request-available
>
> Hadoop allows the configuration of a credential provider path through the 
> property "{*}hadoop.security.credential.provider.path{*}", and the 
> {{Configuration#getPassword()}} method retrieves the credentials from this 
> provider.
> However, using common credential provider properties for components like 
> Hive, HDFS, and MapReduce can cause issues when they want to configure 
> separate JCEKS files for credentials. For example, the value in the 
> core-site.xml property file can be overridden by the hive-site.xml property 
> file. To resolve this, all components should share a common credential 
> provider path and add all their credentials.
> Azure storage supports account-specific credentials, and thus the credential 
> provider should permit the configuration of separate JCEKS files for each 
> account, such as the property 
> "{*}fs.azure.account.credential.provider.path.<account>.blob.core.windows.net{*}".
> To accommodate this, the {{Configuration#getPassword()}} method should accept 
> a custom property for the credential provider path and retrieve its value. 
> The current default property can be overridden to achieve this.
> {code:java}
> public char[] getPassword(String name) throws IOException {
>     ......
>     ......
> }
> public char[] getPassword(String name, String providerKey) throws IOException 
> {                  
>     ......
>     ......
>  }{code}
>  
> One Example is, Ambari 
> [CustomServiceOrchestrator|https://github.com/apache/ambari/blob/trunk/ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py#L312]
>  service override the core-site.xml value for other component. This fix is 
> very much needed for Ambari. 
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to