hadoop-common-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] (HADOOP-8758) Support for pluggable token implementations
Date Tue, 04 Sep 2012 23:10:08 GMT

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

Daryn Sharp commented on HADOOP-8758:
-------------------------------------

@Eric: Today, hadoop's rpc security as all predicated on kerberos so the gateway daemon would
require kerberos auth (keytab) to communicate with other hadoop daemons.  The NN and other
daemons issuing tokens need to be configured to trust the gateway daemon as a quasi-root user
so it can pretend to be other users.  This is the "proxy token" support currently used by
oozie.  The oozie server is kerberos auth-ed and the other daemons allow oozie to request
tokens to masquerade as other users.

Proxy tokens provide hadoop with rudimentary support for non-kerberos auth, albeit in a questionably
secure way.  If I could successfully exploit an oozie server or gateway and gain access to
its keytab, then I could access almost anyone's data.  It would be more secure if the hadoop
daemons directly support other auth methods to avoid having quasi-root users configured within
the system.

bq. I really like the idea of code path elimination!
Me too, especially in this case!  Less security code paths by always using tokens for authz
would be a dream come true.  The code would be streamlined, and devs w/o access to a secure
cluster would know if they broke tokens, regardless of whether kerberos, ldap, etc, or no
security is enabled.
                
> 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