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