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 >
