[
https://issues.apache.org/jira/browse/HADOOP-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096392#comment-14096392
]
Kai Zheng commented on HADOOP-10959:
------------------------------------
bq.I'm not sure why generating principals and keytabs seems to be viewed as a
difficult activity.
Yes generating principals and keytabs shouldn't be difficult in normal form,
but would be difficult in a dynamic scheduled environment like YARN. We should
also consider the distribution of the keytabs. Regarding this, perhaps
developers from Slider project have the real feeling.
bq.Most if not nearly all large corporations already use kerberos in some form
Quite agree, so this solution bases on Kerberos to support the token mechanism.
We're not coming up something in line with Kerberos or the Kerberos
Authentication Method in Hadoop, but enhance and extend them compatibly.
bq.My impression it's a misnomer to call this a pre-auth extension? It's not a
hardening like the encrypted timestamp pre-auth, but instead is a complete
substitute for a password/keytab. Doesn't this completely undermine kerberos?
Well, let me update verbosely. Classically in RFC4120, Kerberos defined a
preauth phase in KDC exchange to alleviate password attack, your mentioned
timestamp preauth is right here. Note by employing the preauth, it also allowed
to extend the Kerberos protocol and prove the identity of a principal otherwise
than just password. In fact PKINIT(RFC4556) was defined to prove principal
identity with x509 certificate. Then, FAST(RFC6113) defines a a generalized
framework for better defining a preauth mechanism, and in this framework
OTP(RFC6560) was defined, and token-preauth is being defined. OTP preauth
allows to use a one time password, and token-preauth use a JWT token, to prove
the identity instead of password. For end users (not service principal), in
fact password or key won't be a must and can be purged at all. Note both AD and
MIT Kerberos implemented FAST and PKINIT, so don't worry about it.
token-preauth conforms to all these and won't undermine Kerberos.
bq.Will cross-realm authentication work? Do all KDCs in the trust have to use
the custom plugin?
Cross-realm trust works in Kerberos itself, and in practice MIT KDC trusting AD
is deployed well. Like trusting another KDC, a KDC can trust a token
issuer/authority. All the trusts can work together or by itself, but not get
mixed together. So a MIT KDC can trust an AD for a set of users and a token
authority for another set of users at the same time in a deployment, and the
token-preauth plugin is only needed by the MIT KDC.
bq.how do tasks running in the cluster authenticate under the model? Do they
continue to use the existing delegation tokens obtained via JWT/TGT during job
submission
I would think yes. The JWT token support is mainly for the initial
authentication before accessing to Hadoop. I think delegation token works well
internally to bypass some Kerberos constraint. Before we could push Kerberos to
evolve to resolve such limits, nothing we can do for now.
bq.are they using the JWT tokens to obtain a TGT/TGS in the tasks? I think the
latter?
Great idea. Should this go so far I don't know. Maybe in the long future Hadoop
can achieve to that, all tokens are unified into one (a standardized JWT token
that works both internally and externally), but not for now I guess.
bq.Mention is made of an AD-TOKEN which I believe is a non-standard MS
extension? Do you envision the JWT issuer containing the group mapping for all
services?
Yes token-preauth (with the new AD-TOKEN) is to be standardized. In this
extension, JWT token MAY(not REQUIRE) contain groups and also other useful
attributes. If it does, then such attribute(s) can be extracted and employed
for authorization. If otherwise, no hurt at all and groups mapping can still
fall back to original providers.
bq.something like certificates or private keys or shared secret to be involved
- which would be an equal but different "pain to deploy"?
Yes certificates or tokens may be involved, but can be done with less (not just
different) pain. In YARN/Slider totally dynamically scheduled environment,
think about how to prepare for the long time running service principals and
keytabs to be scheduled to run in dynamic containers?
> A Complement and Short Term 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)
