hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4056) Always start the NN's SecretManager
Date Wed, 31 Oct 2012 21:35:12 GMT

    [ 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

Mime
View raw message