Hi Jason, As noticed by you, the current proposal does not support rotation of secret. We also discussed about maintaining a list of secret keys. Other option could be using the controller to generate and rotate secret and distribute it to all brokers. I will update the possible alternatives to future work section of KIP.
On Wed, Feb 8, 2017 at 6:40 AM, 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 > > >
