Hi Roger, In the current proposal, we only allow a user to get delegation token for that user only. Anyone who gets that token can impersonate the user on the broker.
Yes, In future we can extend the support to allow a user to acquire delegation tokens for other users. Pl refer discuss mail thread for impersonation related discussion. Thanks, Manikumar On Wed, Feb 8, 2017 at 8:37 AM, Roger Hoover <roger.hoo...@gmail.com> wrote: > Hi Jun, > > How does it allow impersonation at the connection level? Looking at the > KIP, the DelegationTokenRequest does not have an "Owner" field that can be > set. The owner field of the DelegationTokenResponse says it's the "Kakfa > Principal which requested the delegation token". For impersonation, don't > we need to be able to get tokens for other users besides the one making the > request? > > Thanks, > > Roger > > On Tue, Feb 7, 2017 at 6:45 PM, Jun Rao <j...@confluent.io> wrote: > > > Hi, Roger, > > > > Just to clarify. This KIP already allows you to do impersonation at the > > connection level. Are you talking about impersonation at the request > level? > > > > Thanks, > > > > Jun > > > > On Tue, Feb 7, 2017 at 5:53 PM, Roger Hoover <roger.hoo...@gmail.com> > > wrote: > > > > > Just wondering...how difficult would be it be to later add > impersonation > > ( > > > https://issues.apache.org/jira/browse/KAFKA-3712)? One use case would > > be > > > a > > > Kafka admin UI that would take action on the cluster on behalf > different > > > users. I suppose we could later add an "effectiveUserId" (in Unix > > > terminology) to the token details? > > > > > > On Tue, Feb 7, 2017 at 5:25 PM, Grant Henke <ghe...@cloudera.com> > wrote: > > > > > > > +1 from me as well. > > > > > > > > On Tue, Feb 7, 2017 at 7:10 PM, Jason Gustafson <ja...@confluent.io> > > > > wrote: > > > > > > > > > Looks like a great proposal! I noticed that key rotation is not > > > included. > > > > > That may be reasonable for the initial work, but it might be nice > to > > > > share > > > > > some thoughts on how that might work in the future. For example, I > > > could > > > > > imagine delegation.token.master.key could be a list, which would > > allow > > > > > users to support both a new and old key at the same time while > > clients > > > > are > > > > > upgrading keys. > > > > > > > > > > -Jason > > > > > > > > > > On Tue, Feb 7, 2017 at 4:42 PM, Gwen Shapira <g...@confluent.io> > > > wrote: > > > > > > > > > > > Read the KIP again and I think it looks good. > > > > > > > > > > > > +1 from me. > > > > > > > > > > > > On Tue, Feb 7, 2017 at 3:05 PM, Jun Rao <j...@confluent.io> > wrote: > > > > > > > Hi, Mani, > > > > > > > > > > > > > > If a token expires, then every broker will potentially try to > > > delete > > > > it > > > > > > > around the same time, but only one will succeed. So, we will > have > > > to > > > > > deal > > > > > > > with failures in that case? Another way is to let just one > broker > > > > (say, > > > > > > the > > > > > > > controller) deletes expired tokens. > > > > > > > > > > > > > > It would also be helpful for others to give feedback on this > KIP. > > > > > Rajini, > > > > > > > Gwen, Ismael? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > On Sun, Feb 5, 2017 at 9:54 AM, Manikumar < > > > manikumar.re...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi Jun, > > > > > > >> > > > > > > >> Please see the replies inline. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > >> > > Only one broker does the deletion. Broker updates the > > > expiration > > > > > in > > > > > > its > > > > > > >> > > local cache > > > > > > >> > > and on zookeeper so other brokers also get notified and > > their > > > > > cache > > > > > > >> > > statuses are updated as well. > > > > > > >> > > > > > > > > >> > > > > > > > > >> > Which broker does the deletion? > > > > > > >> > > > > > > > >> > > > > > > >> Any broker can handle the create/expire/renew/describe > > > > delegationtoken > > > > > > >> requests. > > > > > > >> changes are propagated through zk notifications. Every broker > > is > > > > > > >> responsible for > > > > > > >> expiring the tokens. This check be can done during request > > > handling > > > > > time > > > > > > >> and/or > > > > > > >> during token authentication time. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > 110. The diagrams in the wiki still show MD5 digest. Could > you > > > > > change > > > > > > it > > > > > > >> to > > > > > > >> > SCRAM? > > > > > > >> > > > > > > > >> > > > > > > > >> Updated the diagram. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> Thanks, > > > > > > >> Manikumar > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > >> > > Thanks. > > > > > > >> > > Manikumar > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar < > > > > > > >> manikumar.re...@gmail.com> > > > > > > >> > > > wrote: > > > > > > >> > > > > > > > > > >> > > > > Hi, > > > > > > >> > > > > > > > > > > >> > > > > I would like to initiate the vote on KIP-48: > > > > > > >> > > > > > > > > > > >> > > > > https://cwiki.apache.org/ > confluence/display/KAFKA/KIP- > > 48+ > > > > > > >> > > > > Delegation+token+support+for+Kafka > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > Thanks, > > > > > > >> > > > > Manikumar > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gwen Shapira > > > > > > Product Manager | Confluent > > > > > > 650.450.2760 | @gwenshap > > > > > > Follow us: Twitter | blog > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Grant Henke > > > > Software Engineer | Cloudera > > > > gr...@cloudera.com | twitter.com/gchenke | > linkedin.com/in/granthenke > > > > > > > > > >
