hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kan Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8758) Support for pluggable token implementations
Date Wed, 05 Sep 2012 06:23:08 GMT

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

Kan Zhang commented on HADOOP-8758:
-----------------------------------

Thanks all for your comments.

[~eric14], one use case is exactly the Gateway model you mentioned. Suppose a cluster can
be accessed only through a gateway machine and the gateway is configured to authenticate its
external clients using some other method (e.g., LDAP). We want to turn on Hadoop security
within the cluster to support multi-tenancy, but we don't want to invest in Kerberos. One
thing we can do is pre-generate and configure a shared key between Gateway and NN during install
and use it to set up a secure connection between Gateway and NN in place of Kerberos. With
pluggable interface to support multiple types of delegation tokens, such shared keys can be
implemented in the form of a special kind of tokens and only connections authenticated using
these special tokens can be used to fetch delegation tokens. In other words, these special
tokens are used in place of Kerberos tickets to bootstrap security. The difference is Kerberos
mechanism is more general; it can be used by any Kerberized clients without install changes.
Whereas here we need to pre-configure our special tokens in a pair-wise manner for any pair
of entities that we need to enable authenticated connections. Hence, its usefulness is limited
to pre-known services, not arbitrary clients.

[~revans2] and [~daryn], I agree we should allow "SIMPLE" auth to be coupled with tokens.

[~owen.omalley], actually I'm proposing we use the same authentication mechanism as existing
delegation tokens use (yes, we may need to consider upgrading the mechanism at some point
and it depends on what's available in standard libs). What's new here is a new type of credentials,
hence a new type of SecretManager to deal with it. Since the SecretManagers will be stacked
together and deal with different types of credentials, they are orthogonal and can evolve
independently. HTTP could be used for fetching tokens, but the root issue here is which auth
method to use for intra-cluster authentication (ex. between Gateway and NN) and preferably
we don't want to introduce an external dependency (ex, LDAP or Kerberos KDC). We could use
a shared key based mechanism on HTTP, but that doesn't save us any trouble in configuring
the shared keys. We might as well use RPC with its existing token framework.

[~tucu00] Agree with decoupling intra-cluster authentication from user-facing authentication.
This JIRA is a step in that direction. Regarding consolidating different token implementations,
I see the benefit and have discussed it with you and others. Let's leave it to another topic.
                
> Support for pluggable token implementations
> -------------------------------------------
>
>                 Key: HADOOP-8758
>                 URL: https://issues.apache.org/jira/browse/HADOOP-8758
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: ipc, security
>            Reporter: Kan Zhang
>            Assignee: Kan Zhang
>
> Variants of the delegation token mechanism have been employed by different Hadoop services
(NN, JT, RM, etc) to re-authenticate a previously Kerberos-authenticated client. While existing
delegation token mechanism compliments Kerberos well, it doesn't necessarily have to be coupled
with Kerberos. In principle, delegation tokens can be coupled with any authentication mechanism
that bootstraps security. In particular, it can be coupled with other token implementations
that use the same DIGEST-MD5 auth method. For example, a token can be pre-generated in an
out-of-band manner and configured as a shared secret key between NN and JT to allow JT to
make initial authentication to NN. This simple example doesn't deal with token renewal etc,
but it helps to illustrate the point that if we can support multiple pluggable token implementations,
it opens up the possibility for different users to plug in the token implementation of their
choice to bootstrap security. Such token based mechanism has advantages over Kerberos in that
1) it doesn't require Kerberos infrastructure, 2) it leverages existing SASL DIGEST-MD5 auth
method and doesn't require adding a new RPC auth method.

--
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