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