[
https://issues.apache.org/jira/browse/HADOOP-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098399#comment-14098399
]
Kai Zheng commented on HADOOP-10959:
------------------------------------
bq.Undermine as in bypassing a password/keytab means kerberos is no longer the
source of truth for passwords.
In Kerberos password for end user has its own weakness and inconvenience,
that's why today's Kerberos is evolving to support other credentials or
approaches to prove principal's identity, PKINIT (x509 certificate), OTP (One
Time Password), S4U (Protocol transition), and also this newly proposed
token-preauth (JWT token). All these extensions were/are not undermining as you
might mean. MIT Kerberos has a strong wish to support JWT token, which could
open the door to support OAuth 2.0 widely used in internet and cloud for
existing Kerberized distributed systems (like Hadoop). Lacking of such
extensions will result in two options in some deployments, either giving up
Kerberos at all, or trying to bypass its inconvenience (like in Hadoop you can
find some examples, bypass SPNEGO in browser access and use delegation token
externally, rather like hack right).
In such extensions listed above, other identity systems are trusted and
credentials from the sources are employed to acquire TGT so that users can
continue to access Kerberized systems without requiring such systems to be
modified to support the identity systems or credentials directly. Today's
Kerberos including AD and MIT all go in this way and I would think Hadoop
platform should also follow the way if possible in future.
bq.Will jwt support revoking a kvno?
In token-preauth, JWT token doesn't have to correspond to Kerberos key(kvno).
The user using JWT token for login can have no key at all.
bq.After a referral is issued in a cross-realm setup, will the KDC continue to
trust the origin KDC
How preauth mechanism handles cross-realm depends on the mechanism itself.
token-preauth works for the set of users in its local KDC, and may not support
cross-realm for AD, though the KDC supports cross-realm to AD, but for another
set of users.
bq.How will the jwt be injected in the TGT/TGS?
KDC (AS/TGS) decrypts, verifies signature of and validates JWT token according
to JWT token specs, with the trusting setup configuration in MIT KDC for the
trusted token authority.
bq.If the user kdc (usually AD) doesn't have the jwt plug-in, how does the jwt
get injected into tickets after the referral to the (possibly MIT) cluster kdc?
As told above, token-preauth itself may not support cross-realm to AD for its
early stage since AD client may not support to input token at all. In such
case, tickets from users from AD won't get token included, but it doesn't hurt
for Hadoop. In our prototype, if tickets contain token, then respect it and its
attributes. But if don't, fallback to original providers.
bq.it's a terrible idea. I was just seeking clarification
Well I agree, but not absolutely. Just by the way (out of the scope), how YARN
would support Kerberized applications written before Hadoop (and the delegation
token stuff) transparently if ever necessary? I'm asking this because YARN
claims to support that, not to say long time running services.
bq. I'm not certain how I feel about the service not being its own source of
authority for groups...
Well, if you deploy TokenAuth with this solution or whatever one, you surely
trust the token authority you set up for your cluster, and of course trust the
tokens from the authority, right. But if you don't want to deploy, it's easy
and by default, nothing hurts I'm sure. All goes to Kerberos itself as usually.
bq.Storm already does this. The level of security is arguable, but it routinely
pushes new forwardable TGTs to the topology.
Hmmm, I'm not sure. Would you clarify in details. How the principal and keytab
get prepared for a service to run in a container on an unknown node during
scheduling phase by Resource Manager without kadmin's help? I'm not sure
forwardable TGT can serve for that purpose. Yes a task/app can use forwardable
TGT to authenticate itself to KDC, but not my question (for service).
> A complement solution to TokenAuth based on Kerberos pre-authentication
> framework
> ---------------------------------------------------------------------------------
>
> Key: HADOOP-10959
> URL: https://issues.apache.org/jira/browse/HADOOP-10959
> Project: Hadoop Common
> Issue Type: New Feature
> Components: security
> Reporter: Kai Zheng
> Assignee: Kai Zheng
> Labels: Rhino
> Attachments: KerbToken-v2.pdf
>
>
> To implement and integrate pluggable authentication providers, enhance
> desirable single sign on for end users, and help enforce centralized access
> control on the platform, the community has widely discussed and concluded
> token based authentication could be the appropriate approach. TokenAuth
> (HADOOP-9392) was proposed and is under development to implement another
> Authentication Method in lieu with Simple and Kerberos. It is a big and long
> term effort to support TokenAuth across the entire ecosystem. We here propose
> a short term replacement based on Kerberos that can complement to TokenAuth.
> Our solution involves less codes changes with limited risk and the main
> development work has already been done in our POC. Users can use our solution
> as a short term solution to support token inside Hadoop.
> This effort and resultant solution will be fully described in the design
> document to be attached. And the brief introduction will be commented.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
