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