[
https://issues.apache.org/jira/browse/HADOOP-11748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380874#comment-14380874
]
Haohui Mai commented on HADOOP-11748:
-------------------------------------
Just to echo [~rkanter]'s comments on HADOOP-10670:
{quote}
I took a look at AuthenticationFilterInitializer and you're right; that appears
to be how it worked before. When working on HADOOP-10868 and HADOOP-10791, I
didn't realize that. The motivation for that work had been Oozie HA, and we
didn't have the code in AuthenticationFilterInitializer, so it had previously
been reading a secret string directly from the configuration (which I know is
bad). It's good that we have that sorted out now though
{quote}
> Secrets for auth cookies can be specified in clear text
> -------------------------------------------------------
>
> Key: HADOOP-11748
> URL: https://issues.apache.org/jira/browse/HADOOP-11748
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Haohui Mai
> Priority: Critical
>
> Based on the discussion on HADOOP-10670, this jira proposes to remove
> {{StringSecretProvider}} as it opens up possibilities for misconfiguration
> and security vulnerabilities.
> {quote}
> My understanding is that the use case of inlining the secret is never
> supported. The property is used to pass the secret internally. The way it
> works before HADOOP-10868 is the following:
> * Users specify the initializer of the authentication filter in the
> configuration.
> * AuthenticationFilterInitializer reads the secret file. The server will not
> start if the secret file does not exists. The initializer will set the
> property if it read the file correctly.
> *There is no way to specify the secret in the configuration out-of-the-box –
> the secret is always overwritten by AuthenticationFilterInitializer.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
