[
https://issues.apache.org/jira/browse/HDFS-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488252#comment-13488252
]
Daryn Sharp commented on HDFS-4056:
-----------------------------------
bq. I'm not sure we support an insecure cluster to talk to a secure one right
now.
Yes, it should work if you fetch the token yourself. For clarification, the
way it currently works:
* Insecure cluster:
** NN always returns no token (null) if client asks for one
** Client correctly handles null response as security disabled
** Client passes token, if present, in subsequent connections - tokens
currently will never be present, unless fetchdt is used to obtain one from a
secure cluster
** If a client attempts to use a token, the NN tells it to revert to SIMPLE
* Secure cluster:
** NN returns token if:
**# client is kerberos, else throws exception for other auths (like token)
**# if the secret manager is running, else returns null like an insecure cluster
** Client passes token, if present, in subsequent connections
This allows secure and insecure clusters to interoperate under the right
conditions. The main difference is insecure clients only fetch tokens if
explicitly requested, whereas secure clients automatically attempt to fetch
tokens. Both always send tokens if available, and both interpret no token from
an NN to mean security is disabled.
bq. That [the secret manager running?] would be very confusing and I certainly
don't want to see it happen in my production cluster. I may configure a cluster
to use either SIMPLE + SIMPLE or SIMPLE + TOKEN for different purposes, but I
don't see why I want to mix them up, especially at production (there is no
security benefit, only overhead).
What would be the confusion? With this patch alone, there is no change and
zero overhead for clients of an insecure cluster. Clients from a secure
cluster will however be able to request and use tokens on the insecure cluster.
bq. If the conf says SIMPLE + SIMPLE, then even if a token is present, it
shouldn't be used. That token may be from a stale token file. RPC Client
shouldn't even waste its time looking for tokens.
Trust me, I've dealt with so many token issues that my poor wife knows what
they are. :) I don't recall a problem ever being root-caused to a stale token
file. The overhead of the RPC client looking for a token in an empty
collection in the UGI is negligible/moot.
Although there is no security benefit for an insecure cluster, the huge benefit
is to the hadoop codebase by moving towards the elimination of multiple code
paths related to security. We can decrease the complexity and increase the
code coverage. Most importantly, we can remove the fragility caused by people
accidentally breaking tokens because they have no access to a secure cluster.
> Always start the NN's SecretManager
> -----------------------------------
>
> Key: HDFS-4056
> URL: https://issues.apache.org/jira/browse/HDFS-4056
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: name-node
> Affects Versions: 0.23.0, 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: HDFS-4056.patch
>
>
> To support the ability to use tokens regardless of whether kerberos is
> enabled, the NN's secret manager should always be started.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
