kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manikumar <manikumar.re...@gmail.com>
Subject Re: [DISCUSS] KIP-48 Support for delegation tokens as an authentication mechanism
Date Thu, 15 Dec 2016 09:04:57 GMT
@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 <kafka@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 <ismael@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 <rsivaram@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.reddy@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 <gwen@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.reddy@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.reddy@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 <
> > > asingh@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 <
> > > > gwen@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 <
> > > > > > > kafka@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 <
> > > > > > asingh@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 <
> > > > > > gwen@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 <
> > > > jun@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 <
> > > > > > > >
> > > > > > > > > asingh@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
> > > > > > > >
> > > > > > > > > > >> > >> <kafka@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 <
> > > > > > > >
> > > > > > > > > > asingh@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 <
> > > > > > > >
> > > > > > > > > > >> > kafka@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
> > > > > > > >
> > > > > > > > > > >> > >>> > > <ghenke@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 <
> > > > > > > >
> > > > > > > > > jun@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.parth@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
> > > > > > > >
> > > > > > > > > > >> > >>> > > > > > <jun@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.parth@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 <
> > > > > > > >
> > > > > > > > > > >> > jun@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 <
> > > > > > > >
> > > > > > > > > > >> > >>> jun@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 <
> > > > > > > >
> > > > > > > > > > >> > >>> > > > > gwen@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
> > > > > > <
> > > > > > > >
> > > > > > > > > > >> > >>> kafka@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.parth@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
> > > > > > > >
> > > > > > > > > > >> > >>> > > > > > > user1@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-user@EXAMPLE.COM
> > > ,
> > > > > > > >
> > > > > > > > > > >> > >>> > storm-nimbus@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
> > > > > > > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message