Thanks. I found the other discussion thread. Sorry for being behind on this.
I'm interested in the future impersonation use cases. This seems to get us closer. +1 (non-binding) On Wed, Feb 8, 2017 at 4:41 AM, Manikumar <manikumar.re...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > >
