Hi Devs, If there are no more comments, I will start vote on this KIP later this week.
Thanks On Fri, Dec 16, 2016 at 12:28 PM, Manikumar <manikumar.re...@gmail.com> wrote: > Hi, > > >> Can you add a sample Jaas configuration using delegation tokens to the >> KIP? >> > > Will add sample Jaas configuration. > > >> To make sure I have understood correctly, KAFKA-3712 is aimed at enabling >> a >> superuser to impersonate another (single) user, say alice. A producer >> using >> impersonation will authenticate with superuser credentials. All requests >> from the producer will be run with the principal alice. But alice is not >> involved in the authentication and alice's credentials are not actually >> provided to the broker? >> >> > Yes, this matches with my understanding of impersonation work . Even in > this approach > we have to handle all producer related issues mentioned by you. Yes, this > is big change > and can be implemented if there is a pressing need. I hope we are all in > agreement, that > this can be done in a separate KIP. > > > I request others give any suggestions/concerns on this KIP. > > > Thanks, > > > >> >> On Thu, Dec 15, 2016 at 9:04 AM, Manikumar <manikumar.re...@gmail.com> >> wrote: >> >> > @Gwen, @Rajini, >> > >> > As mentioned in the KIP, main motivation for this KIP is to reduce load >> on >> > Kerberos >> > server on large kafka deployments with large number of clients. >> > >> > Also it looks like we are combining two overlapping concepts >> > 1. Single client sending requests with multiple users/authentications >> > 2. Impersonation >> > >> > Option 1, is definitely useful in some use cases and can be used to >> > implement workaround for >> > impersonation >> > >> > In Impersonation, a super user can send requests on behalf of another >> > user(Alice) in a secured way. >> > superuser has credentials but user Alice doesn't have any. The requests >> are >> > required >> > to run as user Alice and accesses/ACLs on Broker are required to be >> done as >> > user Alice. >> > It is required that user Alice can connect to the Broker on a connection >> > authenticated with >> > superuser's credentials. In other words superuser is impersonating the >> user >> > Alice. >> > >> > The approach mentioned by Harsha in previous mail is implemented in >> hadoop, >> > storm etc.. >> > >> > Some more details here: >> > https://hadoop.apache.org/docs/r2.7.2/hadoop-project- >> > dist/hadoop-common/Superusers.html >> > >> > >> > @Rajini >> > >> > Thanks for your comments on SASL/SCRAM usage. I am thinking to send >> > tokenHmac (salted-hashed version) >> > as password for authentication and tokenID for retrial of tokenHmac at >> > server side. >> > Does above sound OK? >> > >> > >> > Thanks, >> > Manikumar >> > >> > On Wed, Dec 14, 2016 at 10:33 PM, Harsha Chintalapani <ka...@harsha.io> >> > wrote: >> > >> > > @Gwen @Mani Not sure why we want to authenticate at every request. >> Even >> > if >> > > the token exchange is cheap it still a few calls that need to go >> through >> > > round trip. Impersonation doesn't require authentication for every >> > > request. >> > > >> > > "So a centralized app can create few producers, do the metadata >> request >> > and >> > > broker discovery with its own user auth, but then use delegation >> tokens >> > to >> > > allow performing produce/fetch requests as different users? Instead of >> > > having to re-connect for each impersonated user?" >> > > >> > > Yes. But what we will have is this centralized user as impersonation >> user >> > > on behalf of other users. When it authenticates initially we will >> create >> > a >> > > "Subject" and from there on wards centralized user can do >> > > Subject.doAsPrivileged >> > > on behalf, other users. >> > > On the server side, we can retrieve two principals out of this one is >> the >> > > authenticated user (centralized user) and another is impersonated >> user. >> > We >> > > will first check if the authenticated user allowed to impersonate and >> > then >> > > move on to check if the user Alice has access to the topic "X" to >> > > read/write. >> > > >> > > @Rajini Intention of this KIP is to support token auth via SASL/SCRAM, >> > not >> > > just with TLS. What you raised is a good point let me take a look and >> > add >> > > details. >> > > >> > > It will be easier to add impersonation once we reach agreement on this >> > KIP. >> > > >> > > >> > > On Wed, Dec 14, 2016 at 5:51 AM Ismael Juma <ism...@juma.me.uk> >> wrote: >> > > >> > > > Hi Rajini, >> > > > >> > > > I think it would definitely be valuable to have a KIP for >> > impersonation. >> > > > >> > > > Ismael >> > > > >> > > > On Wed, Dec 14, 2016 at 4:03 AM, Rajini Sivaram < >> rsiva...@pivotal.io> >> > > > wrote: >> > > > >> > > > > It would clearly be very useful to enable clients to send >> requests on >> > > > > behalf of multiple users. A separate KIP makes sense, but it may >> be >> > > worth >> > > > > thinking through some of the implications now, especially if the >> main >> > > > > interest in delegation tokens comes from its potential to enable >> > > > > impersonation. >> > > > > >> > > > > I understand that delegation tokens are only expected to be used >> with >> > > > TLS. >> > > > > But the choice of SASL/SCRAM for authentication must be based on a >> > > > > requirement to protect the tokenHmac - otherwise you could just >> use >> > > > > SASL/PLAIN. With SASL/SCRAM the tokenHmac is never propagated >> > > > on-the-wire, >> > > > > only a salted-hashed version of it is used in the SASL >> authentication >> > > > > exchange. If impersonation is based on sending tokenHmac in >> requests, >> > > any >> > > > > benefit of using SCRAM is lost. >> > > > > >> > > > > An alternative may be to allow clients to authenticate multiple >> times >> > > > using >> > > > > SASL and include one of its authenticated principals in each >> request >> > > > > (optionally). I haven't thought it through yet, obviously. But if >> the >> > > > > approach is of interest and no one is working on a KIP for >> > > impersonation >> > > > at >> > > > > the moment, I am happy to write one. It may provide something for >> > > > > comparison at least. >> > > > > >> > > > > Thoughts? >> > > > > >> > > > > >> > > > > On Wed, Dec 14, 2016 at 9:53 AM, Manikumar < >> > manikumar.re...@gmail.com> >> > > > > wrote: >> > > > > >> > > > > > That's a good idea. Authenticating every request with delegation >> > > token >> > > > > will >> > > > > > be useful for >> > > > > > impersonation use-cases. But as of now, we are thinking >> delegation >> > > > token >> > > > > as >> > > > > > just another way >> > > > > > to authenticate the users. We haven't think through all the use >> > cases >> > > > > > related to >> > > > > > impersonation or using delegation token for impersonation. We >> want >> > to >> > > > > > handle impersonation >> > > > > > (KAFKA-3712) as part of separate KIP. >> > > > > > >> > > > > > Will that be Ok? >> > > > > > >> > > > > > >> > > > > > On Wed, Dec 14, 2016 at 8:09 AM, Gwen Shapira < >> g...@confluent.io> >> > > > wrote: >> > > > > > >> > > > > > > Thinking out loud here: >> > > > > > > >> > > > > > > It looks like authentication with a delegation token is going >> to >> > be >> > > > > > > super-cheap, right? We just compare the token to a value in >> the >> > > > broker >> > > > > > > cache? >> > > > > > > >> > > > > > > If I understood the KIP correctly, right now it suggests that >> > > > > > > authentication happens when establishing the client-broker >> > > connection >> > > > > (as >> > > > > > > normal for Kafka. But perhaps we want to consider >> authenticating >> > > > every >> > > > > > > request with delegation token (if exists)? >> > > > > > > >> > > > > > > So a centralized app can create few producers, do the metadata >> > > > request >> > > > > > and >> > > > > > > broker discovery with its own user auth, but then use >> delegation >> > > > tokens >> > > > > > to >> > > > > > > allow performing produce/fetch requests as different users? >> > Instead >> > > > of >> > > > > > > having to re-connect for each impersonated user? >> > > > > > > >> > > > > > > This may over-complicate things quite a bit (basically adding >> > extra >> > > > > > > information in every request), but maybe it will be useful for >> > > > > > > impersonation use-cases (which seem to drive much of the >> interest >> > > in >> > > > > this >> > > > > > > KIP)? >> > > > > > > Kafka Connect, NiFi and friends can probably use this to share >> > > > clients >> > > > > > > between multiple jobs, tasks, etc. >> > > > > > > >> > > > > > > What do you think? >> > > > > > > >> > > > > > > Gwen >> > > > > > > >> > > > > > > On Tue, Dec 13, 2016 at 12:43 AM, Manikumar < >> > > > manikumar.re...@gmail.com >> > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > > > Ashish, >> > > > > > > > >> > > > > > > > Thank you for reviewing the KIP. Please see the replies >> > inline. >> > > > > > > > >> > > > > > > > >> > > > > > > > > 1. How to disable delegation token authentication? >> > > > > > > > > >> > > > > > > > > This can be achieved in various ways, however I think >> reusing >> > > > > > > delegation >> > > > > > > > > token secret config for this makes sense here. Avoids >> > creating >> > > > yet >> > > > > > > > another >> > > > > > > > > config and forces delegation token users to consciously >> set >> > the >> > > > > > secret. >> > > > > > > > If >> > > > > > > > > the secret is not set or set to empty string, brokers >> should >> > > turn >> > > > > off >> > > > > > > > > delegation token support. This will however require a new >> > error >> > > > > code >> > > > > > to >> > > > > > > > > indicate delegation token support is turned off on broker. >> > > > > > > > > >> > > > > > > > >> > > > > > > > Thanks for the suggestion. Option to turnoff delegation >> token >> > > > > > > > authentication will be useful. >> > > > > > > > I'll update the KIP. >> > > > > > > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > 2. ACLs on delegation token? >> > > > > > > > > >> > > > > > > > > Do we need to have ACLs defined for tokens? I do not >> think it >> > > > buys >> > > > > us >> > > > > > > > > anything, as delegation token can be treated as >> impersonation >> > > of >> > > > > the >> > > > > > > > owner. >> > > > > > > > > Any thing the owner has permission to do, delegation >> tokens >> > > > should >> > > > > be >> > > > > > > > > allowed to do as well. If so, we probably won't need to >> > return >> > > > > > > > > authorization exception error code while creating >> delegation >> > > > token. >> > > > > > It >> > > > > > > > > however would make sense to check renew and expire >> requests >> > are >> > > > > > coming >> > > > > > > > from >> > > > > > > > > owner or renewers of the token, but that does not require >> > > > explicit >> > > > > > > acls. >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > Yes, We agreed to not have new acl on who can request >> > delegation >> > > > > token. >> > > > > > > > I'll update the KIP. >> > > > > > > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > 3. How to restrict max life time of a token? >> > > > > > > > > >> > > > > > > > > Admins might want to restrict max life time of tokens >> created >> > > on >> > > > a >> > > > > > > > cluster, >> > > > > > > > > and this can very from cluster to cluster based on >> use-cases. >> > > > This >> > > > > > > might >> > > > > > > > > warrant a separate broker config. >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Currently we have "delegation.token.max.lifetime.sec" >> server >> > > > config >> > > > > > > > property >> > > > > > > > May be we can take min(User supplied MaxTime, Server >> MaxTime) >> > as >> > > > max >> > > > > > life >> > > > > > > > time. >> > > > > > > > I am open to add new config property. >> > > > > > > > >> > > > > > > > Few more comments based on recent KIP update. >> > > > > > > > > >> > > > > > > > > 1. Do we need a separate {{InvalidateTokenRequest}}? >> Can't we >> > > use >> > > > > > > > > {{ExpireTokenRequest}} with with expiryDate set to >> anything >> > > > before >> > > > > > > > current >> > > > > > > > > date? >> > > > > > > > > >> > > > > > > > >> > > > > > > > makes sense. we don't need special request to cancel the >> token. >> > > We >> > > > > can >> > > > > > > use >> > > > > > > > ExpireTokenRequest. >> > > > > > > > I'll update the KIP. >> > > > > > > > >> > > > > > > > >> > > > > > > > > 2. Can we change time field names to indicate their unit >> is >> > > > > > > milliseconds, >> > > > > > > > > like, IssueDateMs, ExpiryDateMs, etc.? >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Done. >> > > > > > > > >> > > > > > > > >> > > > > > > > > 3. Can we allow users to renew a token for a specified >> amount >> > > of >> > > > > > time? >> > > > > > > In >> > > > > > > > > current version of KIP, renew request does not take time >> as a >> > > > > param, >> > > > > > > not >> > > > > > > > > sure what is expiry time set to after renewal. >> > > > > > > > > >> > > > > > > > > >> > > > > > > > Yes, we need to specify renew period. I'll update the KIP. >> > > > > > > > >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Mankumar >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > On Mon, Dec 12, 2016 at 9:08 AM Manikumar < >> > > > > manikumar.re...@gmail.com >> > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > Hi, >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > I would like to reinitiate the discussion on Delegation >> > token >> > > > > > support >> > > > > > > > for >> > > > > > > > > > >> > > > > > > > > > Kafka. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Brief summary of the past discussion: >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > 1) Broker stores delegation tokens in zookeeper. All >> > brokers >> > > > > will >> > > > > > > > have a >> > > > > > > > > > >> > > > > > > > > > cache backed by >> > > > > > > > > > >> > > > > > > > > > zookeeper so they will all get notified whenever a >> new >> > > token >> > > > > is >> > > > > > > > > > >> > > > > > > > > > generated and they will >> > > > > > > > > > >> > > > > > > > > > update their local cache whenever token state >> changes. >> > > > > > > > > > >> > > > > > > > > > 2) The current proposal does not support rotation of >> secret >> > > > > > > > > > >> > > > > > > > > > 3) Only allow the renewal by users that authenticated >> using >> > > > *non* >> > > > > > > > > > >> > > > > > > > > > delegation token mechanism >> > > > > > > > > > >> > > > > > > > > > 4) KIP-84 proposes to support SASL SCRAM mechanisms. >> Kafka >> > > > > clients >> > > > > > > can >> > > > > > > > > > >> > > > > > > > > > authenticate using >> > > > > > > > > > >> > > > > > > > > > SCRAM-SHA-256, providing the delegation token HMAC as >> > > > > password. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Updated the KIP with the following: >> > > > > > > > > > >> > > > > > > > > > 1. Protocol and Config changes >> > > > > > > > > > >> > > > > > > > > > 2. format of the data stored in ZK. >> > > > > > > > > > >> > > > > > > > > > 3. Changes to Java Clients/Usage of SASL SCRAM mechanism >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> > > > > > > > > > >> > > > > > > > > > 48+Delegation+token+support+for+Kafka >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Jun, Ashish, Gwen, >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Pl review the updated KIP. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Thanks >> > > > > > > > > > >> > > > > > > > > > Manikumar >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > On Thu, Sep 29, 2016 at 9:56 PM, Ashish Singh < >> > > > > asi...@cloudera.com >> > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > Harsha/ Gwen, >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > How do we proceed here? I am willing to help out with >> > here. >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > On Fri, Sep 23, 2016 at 11:41 AM, Gwen Shapira < >> > > > > > g...@confluent.io> >> > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > Is it updated? are all concerns addressed? do you >> want >> > to >> > > > > > start a >> > > > > > > > > vote? >> > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > Sorry for being pushy, I do appreciate that we are >> all >> > > > > > volunteers >> > > > > > > > and >> > > > > > > > > > >> > > > > > > > > > > > finding time is difficult. This feature is important >> > for >> > > > > > anything >> > > > > > > > > that >> > > > > > > > > > >> > > > > > > > > > > > integrates with Kafka (stream processors, Flume, >> NiFi, >> > > etc) >> > > > > > and I >> > > > > > > > > > >> > > > > > > > > > > > don't want to see this getting stuck because we lack >> > > > > > coordination >> > > > > > > > > > >> > > > > > > > > > > > within the community. >> > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > On Thu, Sep 15, 2016 at 6:39 PM, Harsha >> Chintalapani < >> > > > > > > > > ka...@harsha.io> >> > > > > > > > > > >> > > > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > > The only pending update for the KIP is to write up >> > the >> > > > > > protocol >> > > > > > > > > > changes >> > > > > > > > > > >> > > > > > > > > > > > like >> > > > > > > > > > >> > > > > > > > > > > > > we've it KIP-4. I'll update the wiki. >> > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > On Thu, Sep 15, 2016 at 4:27 PM Ashish Singh < >> > > > > > > > asi...@cloudera.com> >> > > > > > > > > > >> > > > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> I think we decided to not support secret >> rotation, I >> > > > guess >> > > > > > > this >> > > > > > > > > can >> > > > > > > > > > be >> > > > > > > > > > >> > > > > > > > > > > > >> stated clearly on the KIP. Also, more details on >> how >> > > > > clients >> > > > > > > > will >> > > > > > > > > > >> > > > > > > > > > > > perform >> > > > > > > > > > >> > > > > > > > > > > > >> token distribution and how CLI will look like >> will >> > be >> > > > > > helpful. >> > > > > > > > > > >> > > > > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> On Thu, Sep 15, 2016 at 3:20 PM, Gwen Shapira < >> > > > > > > > g...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > Hi Guys, >> > > > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > > > > >> > This discussion was dead for a while. Are there >> > > still >> > > > > > > > > contentious >> > > > > > > > > > >> > > > > > > > > > > > >> > points? If not, why are there no votes? >> > > > > > > > > > >> > > > > > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > > > > >> > On Tue, Aug 23, 2016 at 1:26 PM, Jun Rao < >> > > > > > j...@confluent.io> >> > > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > > Ashish, >> > > > > > > > > > >> > > > > > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > > Yes, I will send out a KIP invite for next >> week >> > to >> > > > > > discuss >> > > > > > > > > > KIP-48 >> > > > > > > > > > >> > > > > > > > > > > > and >> > > > > > > > > > >> > > > > > > > > > > > >> > other >> > > > > > > > > > >> > > > > > > > > > > > >> > > remaining KIPs. >> > > > > > > > > > >> > > > > > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > > Jun >> > > > > > > > > > >> > > > > > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > > On Tue, Aug 23, 2016 at 1:22 PM, Ashish >> Singh < >> > > > > > > > > > >> > > > > > > > > > > asi...@cloudera.com> >> > > > > > > > > > >> > > > > > > > > > > > >> > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >> Thanks Harsha! >> > > > > > > > > > >> > > > > > > > > > > > >> > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >> Jun, can we add KIP-48 to next KIP hangout's >> > > > agenda. >> > > > > > > Also, >> > > > > > > > we >> > > > > > > > > > did >> > > > > > > > > > >> > > > > > > > > > > > not >> > > > > > > > > > >> > > > > > > > > > > > >> > >> actually make a call on when we should have >> > next >> > > > KIP >> > > > > > > call. >> > > > > > > > As >> > > > > > > > > > >> > > > > > > > > > > there >> > > > > > > > > > >> > > > > > > > > > > > >> > >> are >> > > > > > > > > > >> > > > > > > > > > > > >> > a >> > > > > > > > > > >> > > > > > > > > > > > >> > >> few outstanding KIPs that could not be >> > discussed >> > > > this >> > > > > > > week, >> > > > > > > > > can >> > > > > > > > > > >> > > > > > > > > > > we >> > > > > > > > > > >> > > > > > > > > > > > >> > >> have >> > > > > > > > > > >> > > > > > > > > > > > >> > a >> > > > > > > > > > >> > > > > > > > > > > > >> > >> KIP hangout call next week? >> > > > > > > > > > >> > > > > > > > > > > > >> > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >> On Tue, Aug 23, 2016 at 1:10 PM, Harsha >> > > > Chintalapani >> > > > > > > > > > >> > > > > > > > > > > > >> > >> <ka...@harsha.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >> wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> Ashish, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> Yes we are working on it. Lets >> discuss >> > > in >> > > > > the >> > > > > > > next >> > > > > > > > > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> meeting. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> I'll join. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> -Harsha >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> On Tue, Aug 23, 2016 at 12:07 PM Ashish >> Singh >> > < >> > > > > > > > > > >> > > > > > > > > > > > asi...@cloudera.com> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > Hello Harsha, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > Are you still working on this? Wondering >> if >> > we >> > > > can >> > > > > > > > discuss >> > > > > > > > > > >> > > > > > > > > > > this >> > > > > > > > > > >> > > > > > > > > > > > in >> > > > > > > > > > >> > > > > > > > > > > > >> > next >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > meeting, if you can join. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > On Mon, Jul 18, 2016 at 9:51 AM, Harsha >> > > > > > Chintalapani < >> > > > > > > > > > >> > > > > > > > > > > > >> > ka...@harsha.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > Hi Grant, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > We are working on it. Will >> add >> > the >> > > > > > details >> > > > > > > > to >> > > > > > > > > > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > about >> > > > > > > > > > >> > > > > > > > > > > > >> > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > request protocol. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > Harsha >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > On Mon, Jul 18, 2016 at 6:50 AM Grant >> > Henke >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > <ghe...@cloudera.com> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > Hi Parth, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > Are you still working on this? If you >> > need >> > > > any >> > > > > > > help >> > > > > > > > > > please >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > don't >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > hesitate >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > to ask. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > Grant >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > On Thu, Jun 30, 2016 at 4:35 PM, Jun >> > Rao < >> > > > > > > > > > >> > > > > > > > > > > j...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > Parth, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > Thanks for the reply. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > It makes sense to only allow the >> > renewal >> > > > by >> > > > > > > users >> > > > > > > > > that >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> authenticated >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > using >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > *non* delegation token mechanism. >> > Then, >> > > > > should >> > > > > > > we >> > > > > > > > > make >> > > > > > > > > > >> > > > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> renewal a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > list? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > For example, in the case of rest >> > proxy, >> > > it >> > > > > > will >> > > > > > > be >> > > > > > > > > > >> > > > > > > > > > > useful >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > for >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> every >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > instance of rest proxy to be able >> to >> > > renew >> > > > > the >> > > > > > > > > tokens. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > It would be clearer if we can >> document >> > > the >> > > > > > > request >> > > > > > > > > > >> > > > > > > > > > > > protocol >> > > > > > > > > > >> > > > > > > > > > > > >> > like >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > https://cwiki.apache.org/confl >> > > > > > > > > uence/display/KAFKA/KIP- >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > 4+-+Command+line+and+ >> > > > > centralized+administrative+ >> > > > > > > > > > >> > > > > > > > > > > > operations#KIP-4- >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > Commandlineandcentralizedadmin >> > > > > > istrativeoperations- >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > CreateTopicsRequest(KAFKA- >> > > > > > > > 2945):(VotedandPlannedforin0. >> > > > > > > > > > >> > > > > > > > > > > > 10.1.0) >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > . >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > It would also be useful to document >> > the >> > > > > client >> > > > > > > > APIs. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > Jun >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > On Tue, Jun 28, 2016 at 2:55 PM, >> parth >> > > > > > > brahmbhatt >> > > > > > > > < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > brahmbhatt.pa...@gmail.com> wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Hi, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > I am suggesting that we will only >> > > allow >> > > > > the >> > > > > > > > > renewal >> > > > > > > > > > by >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > users >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> that >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > authenticated using *non* >> delegation >> > > > token >> > > > > > > > > > mechanism. >> > > > > > > > > > >> > > > > > > > > > > > For >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> example, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > If >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > user >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Alice authenticated using >> kerberos >> > and >> > > > > > > requested >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > delegation >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> tokens, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > only >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > user Alice authenticated via non >> > > > > delegation >> > > > > > > > token >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > mechanism >> > > > > > > > > > >> > > > > > > > > > > > >> > can >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > renew. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Clients that have access to >> > > delegation >> > > > > > tokens >> > > > > > > > can >> > > > > > > > > > not >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > issue >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > renewal >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > request for renewing their own >> token >> > > and >> > > > > > this >> > > > > > > is >> > > > > > > > > > >> > > > > > > > > > > > primarily >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > important >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > reduce the time window for which >> a >> > > > > > compromised >> > > > > > > > > token >> > > > > > > > > > >> > > > > > > > > > > > will >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > be >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> valid. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > To clarify, Yes any authenticated >> > user >> > > > can >> > > > > > > > request >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > delegation >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > tokens >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > but >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > even here I would recommend to >> avoid >> > > > > > creating >> > > > > > > a >> > > > > > > > > > chain >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > where a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > client >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > authenticated via delegation >> token >> > > > request >> > > > > > for >> > > > > > > > > more >> > > > > > > > > > >> > > > > > > > > > > > >> > delegation >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > tokens. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Basically anyone can request >> > > delegation >> > > > > > token, >> > > > > > > > as >> > > > > > > > > > long >> > > > > > > > > > >> > > > > > > > > > > > as >> > > > > > > > > > >> > > > > > > > > > > > >> > they >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > authenticate >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > via a non delegation token >> > mechanism. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Aren't classes listed here >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > https://cwiki.apache.org/confl >> > > > > > > > > uence/display/KAFKA/KIP- >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > 48+Delegation+token+support+fo >> > > > > > > > > > >> > > > > > > > > > > r+Kafka#KIP-48Delegationtokens >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> upportforKaf >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > ka-PublicInterfaces >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > sufficient? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Thanks >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > Parth >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > On Tue, Jun 21, 2016 at 4:33 PM, >> Jun >> > > Rao >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > <j...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > Parth, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > Thanks for the reply. A couple >> of >> > > > > comments >> > > > > > > > > inline >> > > > > > > > > > >> > > > > > > > > > > > below. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > On Tue, Jun 21, 2016 at 10:36 >> AM, >> > > > parth >> > > > > > > > > > brahmbhatt < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > brahmbhatt.pa...@gmail.com> >> > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 1. Who / how are tokens >> renewed? >> > > By >> > > > > > > original >> > > > > > > > > > >> > > > > > > > > > > > requester >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> only? or >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > using >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Kerberos >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > auth only? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > My recommendation is to do >> this >> > > only >> > > > > > using >> > > > > > > > > > >> > > > > > > > > > > Kerberos >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > auth >> > > > > > > > > > >> > > > > > > > > > > > >> > and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > only >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > threw >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > renewer specified during the >> > > > > acquisition >> > > > > > > > > > request. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > Hmm, not sure that I follow >> this. >> > > Are >> > > > > you >> > > > > > > > saying >> > > > > > > > > > >> > > > > > > > > > > that >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > any >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> client >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > authenticated with the >> delegation >> > > > token >> > > > > > can >> > > > > > > > > renew, >> > > > > > > > > > >> > > > > > > > > > > > i.e. >> > > > > > > > > > >> > > > > > > > > > > > >> > there >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> is >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > no >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > renewer >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > needed? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > Also, just to be clear, any >> > > > > authenticated >> > > > > > > > client >> > > > > > > > > > >> > > > > > > > > > > > (either >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> through >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > SASL >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > or >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > SSL) can request a delegation >> > token >> > > > for >> > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > authenticated >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> user, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > right? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 2. Are tokens stored on each >> > > broker >> > > > or >> > > > > > in >> > > > > > > > ZK? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > My recommendation is still to >> > > store >> > > > in >> > > > > > ZK >> > > > > > > or >> > > > > > > > > not >> > > > > > > > > > >> > > > > > > > > > > > store >> > > > > > > > > > >> > > > > > > > > > > > >> > them >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> at >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > all. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > The >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > whole controller based >> > > distribution >> > > > is >> > > > > > too >> > > > > > > > > much >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > overhead >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> with >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > not >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > much >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > achieve. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 3. How are tokens >> invalidated / >> > > > > expired? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Either by expiration time >> out or >> > > > > through >> > > > > > > an >> > > > > > > > > > >> > > > > > > > > > > explicit >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> request to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > invalidate. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 4. Which encryption >> algorithm is >> > > > used? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > SCRAM >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 5. What is the impersonation >> > > > proposal >> > > > > > (it >> > > > > > > > > wasn't >> > > > > > > > > > >> > > > > > > > > > > in >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> but >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > was >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > discussed >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > in this thread)? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > There is no imperonation >> > > proposal. I >> > > > > > tried >> > > > > > > > and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > explained >> > > > > > > > > > >> > > > > > > > > > > > >> > how >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > its >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > different problem and why its >> > not >> > > > > really >> > > > > > > > > > necessary >> > > > > > > > > > >> > > > > > > > > > > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> discuss >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > that >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > as >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > part >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > of this KIP. This KIP will >> not >> > > > > support >> > > > > > > any >> > > > > > > > > > >> > > > > > > > > > > > >> > impersonation, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> it >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > will >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > just >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > be >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > another way to authenticate. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 6. Do we need new ACLs, if >> so - >> > > for >> > > > > what >> > > > > > > > > > actions? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > We do not need new ACLs. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > Could we document the format of >> > the >> > > > new >> > > > > > > > > > >> > > > > > > > > > > > request/response >> > > > > > > > > > >> > > > > > > > > > > > >> > and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > their >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > associated Resource and >> Operation >> > > for >> > > > > ACL? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > 7. How would the delegation >> > token >> > > be >> > > > > > > > > configured >> > > > > > > > > > in >> > > > > > > > > > >> > > > > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> client? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Should be through config. I >> > wasn't >> > > > > > > planning >> > > > > > > > on >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > supporting >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> JAAS >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > for >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > tokens. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > I don't believe hadoop does >> this >> > > > > either. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Thanks >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Parth >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > On Thu, Jun 16, 2016 at 4:03 >> PM, >> > > Jun >> > > > > > Rao < >> > > > > > > > > > >> > > > > > > > > > > > >> > j...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > Harsha, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > Another question. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > 9. How would the delegation >> > > token >> > > > be >> > > > > > > > > > configured >> > > > > > > > > > >> > > > > > > > > > > in >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > client? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > The >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > standard >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > way is to do this through >> > JAAS. >> > > > > > However, >> > > > > > > > we >> > > > > > > > > > will >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > need >> > > > > > > > > > >> > > > > > > > > > > > >> > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > think >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > through >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > if >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > this is convenient in a >> shared >> > > > > > > > environment. >> > > > > > > > > > For >> > > > > > > > > > >> > > > > > > > > > > > >> > example, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > when a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > new >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > task >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > is >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > added to a Storm worker >> node, >> > do >> > > > we >> > > > > > need >> > > > > > > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > dynamically >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> add a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > new >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > section >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > in the JAAS file? It may be >> > more >> > > > > > > > convenient >> > > > > > > > > if >> > > > > > > > > > >> > > > > > > > > > > we >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > can >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> pass in >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > token >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > through the config directly >> > w/o >> > > > > going >> > > > > > > > > through >> > > > > > > > > > >> > > > > > > > > > > > JAAS. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > Are you or Parth still >> > actively >> > > > > > working >> > > > > > > on >> > > > > > > > > > this >> > > > > > > > > > >> > > > > > > > > > > > KIP? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > Jun >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > On Sun, Jun 12, 2016 at >> 2:18 >> > PM, >> > > > Jun >> > > > > > > Rao < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> j...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > Just to add on that list. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > 2. It would be good to >> > > document >> > > > > the >> > > > > > > > format >> > > > > > > > > > of >> > > > > > > > > > >> > > > > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > data >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > stored >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > in >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > ZK. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > 7. Earlier, there was a >> > > > discussion >> > > > > > on >> > > > > > > > > > whether >> > > > > > > > > > >> > > > > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > tokens >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > should >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > be >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > propagated through ZK >> like >> > > > > > > > > config/acl/quota, >> > > > > > > > > > >> > > > > > > > > > > or >> > > > > > > > > > >> > > > > > > > > > > > >> > through >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > controller. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > Currently, the >> controller is >> > > > only >> > > > > > > > designed >> > > > > > > > > > for >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> propagating >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > topic >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > metadata, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > but not other data. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > 8. Should we use SCRAM to >> > send >> > > > the >> > > > > > > token >> > > > > > > > > > >> > > > > > > > > > > instead >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > of >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > DIGEST-MD5 >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > since >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > it's >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > deprecated? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > Also, the images in the >> wiki >> > > > seem >> > > > > > > > broken. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > Jun >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > On Fri, Jun 10, 2016 at >> > 10:02 >> > > > AM, >> > > > > > Gwen >> > > > > > > > > > >> > > > > > > > > > > Shapira < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > g...@confluent.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> From what I can see, >> > > remaining >> > > > > > > > questions >> > > > > > > > > > are: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 1. Who / how are tokens >> > > > renewed? >> > > > > By >> > > > > > > > > > original >> > > > > > > > > > >> > > > > > > > > > > > >> > requester >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > only? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > or >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > using >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> Kerberos auth only? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 2. Are tokens stored on >> > each >> > > > > broker >> > > > > > > or >> > > > > > > > in >> > > > > > > > > > ZK? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 3. How are tokens >> > > invalidated / >> > > > > > > > expired? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 4. Which encryption >> > algorithm >> > > > is >> > > > > > > used? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 5. What is the >> > impersonation >> > > > > > proposal >> > > > > > > > (it >> > > > > > > > > > >> > > > > > > > > > > > wasn't >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> in >> > > > > > > > > > >> > > > > > > > > > > > >> > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > but >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > was >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> discussed in this >> thread)? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> 6. Do we need new ACLs, >> if >> > > so - >> > > > > for >> > > > > > > > what >> > > > > > > > > > >> > > > > > > > > > > > actions? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> Gwen >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> On Thu, Jun 9, 2016 at >> 7:48 >> > > PM, >> > > > > > > Harsha >> > > > > > > > < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> ka...@harsha.io> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > Jun & Ismael, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > >> > > > > > > > Unfortunately >> > > > > > > > > I >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > couldn't >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> attend >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > meeting >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > >> > > when >> > > > > > > > > delegation >> > > > > > > > > > >> > > > > > > > > > > > tokens >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > discussed. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > Appreciate >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > if >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > >> > > you >> > > > > can >> > > > > > > > update >> > > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > > >> > thread if >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > you >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > have >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > any >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > >> > > > > further >> > > > > > > > > > questions. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > Thanks, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > Harsha >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> > On Tue, May 24, 2016, >> at >> > > > 11:32 >> > > > > > AM, >> > > > > > > > > Liquan >> > > > > > > > > > >> > > > > > > > > > > Pei >> > > > > > > > > > >> > > > > > > > > > > > >> > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> It seems that the >> links >> > to >> > > > > > images >> > > > > > > in >> > > > > > > > > the >> > > > > > > > > > >> > > > > > > > > > > KIP >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> are >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > broken. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> Liquan >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> On Tue, May 24, 2016 >> at >> > > 9:33 >> > > > > AM, >> > > > > > > > parth >> > > > > > > > > > >> > > > > > > > > > > > >> > brahmbhatt < >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> >> > > brahmbhatt.pa...@gmail.com> >> > > > > > > wrote: >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > 110. What does >> > > > > > > > getDelegationTokenAs >> > > > > > > > > > >> > > > > > > > > > > mean? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > In the current >> > proposal >> > > we >> > > > > > only >> > > > > > > > > allow >> > > > > > > > > > a >> > > > > > > > > > >> > > > > > > > > > > > user >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> get >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > delegation >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > token >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> for >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > the identity that >> it >> > > > > > > authenticated >> > > > > > > > > as >> > > > > > > > > > >> > > > > > > > > > > > using >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> another >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > mechanism, >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > i.e. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> A user >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > that authenticate >> > using >> > > a >> > > > > > keytab >> > > > > > > > for >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > principal >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > us...@example.com >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> will get >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > delegation tokens >> for >> > > that >> > > > > > user >> > > > > > > > > only. >> > > > > > > > > > In >> > > > > > > > > > >> > > > > > > > > > > > >> > future I >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > think >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > we >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > will >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > have >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > extend support such >> > that >> > > > we >> > > > > > > allow >> > > > > > > > > some >> > > > > > > > > > >> > > > > > > > > > > set >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > of >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> users ( >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > >> > > > kafka-rest-u...@example.com >> > > > > , >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > storm-nim...@example.com) >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > acquire >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > delegation tokens >> on >> > > > behalf >> > > > > of >> > > > > > > > other >> > > > > > > > > > >> > > > > > > > > > > users >> > > > > > > > > > >> > > > > > > > > > > > >> > whose >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > identity >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > they >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > have >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > verified >> > independently. >> > > > > Kafka >> > > > > > > > > brokers >> > > > > > > > > > >> > > > > > > > > > > > will >> > > > > > > > > > >> > > > > > > > > > > > >> > have >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> ACLs >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > to >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > control >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> which >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > users are allowed >> to >> > > > > > impersonate >> > > > > > > > > other >> > > > > > > > > > >> > > > > > > > > > > > users >> > > > > > > > > > >> > > > > > > > > > > > >> > and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> get >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > tokens >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > on >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> behalf of >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > them. Overall >> > > > Impersonation >> > > > > > is a >> > > > > > > > > whole >> > > > > > > > > > >> > > > > > > > > > > > >> > different >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > problem >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > in >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > my >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> opinion and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > I think we can >> tackle >> > it >> > > > in >> > > > > > > > separate >> > > > > > > > > > >> > > > > > > > > > > KIP. >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > 111. What's the >> > typical >> > > > rate >> > > > > > of >> > > > > > > > > > getting >> > > > > > > > > > >> > > > > > > > > > > > and >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> renewing >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > delegation >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> tokens? >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > Typically this >> should >> > be >> > > > > very >> > > > > > > very >> > > > > > > > > > low, >> > > > > > > > > > >> > > > > > > > > > > 1 >> > > > > > > > > > >> > > > > > > > > > > > >> > request >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> per >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > minute >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > is a >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > relatively high >> > > estimate. >> > > > > > > However >> > > > > > > > it >> > > > > > > > > > >> > > > > > > > > > > > depends >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > > > > > > > >> >> > on >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> the >> > > > > > > > > > >> > > > > > > > > > > > >> > >>> > > token >> > > > > > > > > > >> > > > >> > > >> > >> > >
