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-
> >
> > > > >> > >>> > > Commandlineandcentralizedadministrativeoperations-
> >
> > > > >> > >>> > > 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
> >
> > > > >> > >>> > > > > > > > > >> expiration. I am
> >
> > > > >> > >>> > > > > > > > > >> >> > less worried about the extra load it
> >
> > > puts
> >
> > > > on
> >
> > > > >> > >>> > controller
> >
> > > > >> > >>> > > > vs
> >
> > > > >> > >>> > > > > > the
> >
> > > > >> > >>> > > > > > > > > added
> >
> > > > >> > >>> > > > > > > > > >> >> > complexity and the value it offers.
> >
> > > > >> > >>> > > > > > > > > >> >> >
> >
> > > > >> > >>> > > > > > > > > >> >> > Thanks
> >
> > > > >> > >>> > > > > > > > > >> >> > Parth
> >
> > > > >> > >>> > > > > > > > > >> >> >
> >
> > > > >> > >>> > > > > > > > > >> >> >
> >
> > > > >> > >>> > > > > > > > > >> >> >
> >
> > > > >> > >>> > > > > > > > > >> >> > On Tue, May 24, 2016 at 7:30 AM,
> > Ismael
> >
> > > > Juma
> >
> > > > >> > >>> > > > > > > > > >> >> > <
> >
> > > > >> > >>> > > > > > > ism...@juma.me.uk>
> >
> > > > >> > >>> > > > > > > > > >> wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> >
> >
> > > > >> > >>> > > > > > > > > >> >> > > Thanks Rajini. It would probably
> >
> > > > require a
> >
> > > > >> > >>> separate
> >
> > > > >> > >>> > > KIP
> >
> > > > >> > >>> > > > > as
> >
> > > > >> > >>> > > > > > it
> >
> > > > >> > >>> > > > > > > > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > introduce user visible changes. We
> >
> > > could
> >
> > > > >> > >>> > > > > > > > > >> >> > > also
> >
> > > > >> > >>> > update
> >
> > > > >> > >>> > > > > KIP-48
> >
> > > > >> > >>> > > > > > > to
> >
> > > > >> > >>> > > > > > > > > >> have this
> >
> > > > >> > >>> > > > > > > > > >> >> > > information, but it seems cleaner
> to
> >
> > > do
> >
> > > > it
> >
> > > > >> > >>> > > separately.
> >
> > > > >> > >>> > > > We
> >
> > > > >> > >>> > > > > > can
> >
> > > > >> > >>> > > > > > > > > >> discuss
> >
> > > > >> > >>> > > > > > > > > >> >> > that
> >
> > > > >> > >>> > > > > > > > > >> >> > > in the KIP call today.
> >
> > > > >> > >>> > > > > > > > > >> >> > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > Ismael
> >
> > > > >> > >>> > > > > > > > > >> >> > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > On Tue, May 24, 2016 at 3:19 PM,
> >
> > > Rajini
> >
> > > > >> > Sivaram
> >
> > > > >> > >>> <
> >
> > > > >> > >>> > > > > > > > > >> >> > > rajinisiva...@googlemail.com>
> > wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > Ismael,
> >
> > > > >> > >>> > > > > > > > > >> >> > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > I have created a JIRA (
> >
> > > > >> > >>> > > > > > > > > >> >> > https://issues.apache.org/
> >
> > > > >> > jira/browse/KAFKA-3751)
> >
> > > > >> > >>> > > > > > > > > >> >> > > > for adding SCRAM as a SASL
> >
> > > mechanism.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > Would
> >
> > > > >> > >>> that
> >
> > > > >> > >>> > > need
> >
> > > > >> > >>> > > > > > > another
> >
> > > > >> > >>> > > > > > > > > >> KIP? If
> >
> > > > >> > >>> > > > > > > > > >> >> > > > KIP-48 will use this mechanism,
> > can
> >
> > > > this
> >
> > > > >> > just
> >
> > > > >> > >>> be
> >
> > > > >> > >>> > a
> >
> > > > >> > >>> > > > JIRA
> >
> > > > >> > >>> > > > > > > that
> >
> > > > >> > >>> > > > > > > > > gets
> >
> > > > >> > >>> > > > > > > > > >> >> > > reviewed
> >
> > > > >> > >>> > > > > > > > > >> >> > > > when the PR is ready?
> >
> > > > >> > >>> > > > > > > > > >> >> > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > Thank you,
> >
> > > > >> > >>> > > > > > > > > >> >> > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > Rajini
> >
> > > > >> > >>> > > > > > > > > >> >> > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > On Tue, May 24, 2016 at 2:46 PM,
> >
> > > > Ismael
> >
> > > > >> > Juma <
> >
> > > > >> > >>> > > > > > > > > ism...@juma.me.uk>
> >
> > > > >> > >>> > > > > > > > > >> >> > wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > Thanks Rajini, SCRAM seems
> like
> > a
> >
> > > > good
> >
> > > > >> > >>> > candidate.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > Gwen had independently
> mentioned
> >
> > > > this
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > as
> >
> > > > >> > a
> >
> > > > >> > >>> SASL
> >
> > > > >> > >>> > > > > > mechanism
> >
> > > > >> > >>> > > > > > > > > that
> >
> > > > >> > >>> > > > > > > > > >> might
> >
> > > > >> > >>> > > > > > > > > >> >> > be
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > useful for Kafka and I have
> been
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > meaning
> >
> > > > >> > to
> >
> > > > >> > >>> > check
> >
> > > > >> > >>> > > > it
> >
> > > > >> > >>> > > > > in
> >
> > > > >> > >>> > > > > > > > more
> >
> > > > >> > >>> > > > > > > > > >> detail.
> >
> > > > >> > >>> > > > > > > > > >> >> > > Good
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > to know that you are willing
> to
> >
> > > > >> > contribute
> >
> > > > >> > >>> an
> >
> > > > >> > >>> > > > > > > > implementation.
> >
> > > > >> > >>> > > > > > > > > >> Maybe
> >
> > > > >> > >>> > > > > > > > > >> >> > we
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > should file a separate JIRA
> for
> >
> > > > this?
> >
> > > > >> > >>> > > > > > > > > >> >> > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > Ismael
> >
> > > > >> > >>> > > > > > > > > >> >> > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > On Tue, May 24, 2016 at 2:12
> PM,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > Rajini
> >
> > > > >> > >>> > Sivaram <
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > rajinisiva...@googlemail.com>
> >
> > > > wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > SCRAM (Salted Challenge
> > Response
> >
> > > > >> > >>> > Authentication
> >
> > > > >> > >>> > > > > > > > Mechanism)
> >
> > > > >> > >>> > > > > > > > > >> is a
> >
> > > > >> > >>> > > > > > > > > >> >> > > better
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > mechanism than Digest-MD5.
> > Java
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > doesn't
> >
> > > > >> > >>> come
> >
> > > > >> > >>> > > > with a
> >
> > > > >> > >>> > > > > > > > > built-in
> >
> > > > >> > >>> > > > > > > > > >> SCRAM
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > SaslServer or SaslClient,
> but
> > I
> >
> > > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > be
> >
> > > > >> > >>> happy
> >
> > > > >> > >>> > > to
> >
> > > > >> > >>> > > > > add
> >
> > > > >> > >>> > > > > > > > > support
> >
> > > > >> > >>> > > > > > > > > >> in
> >
> > > > >> > >>> > > > > > > > > >> >> > Kafka
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > since
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > it would be a useful
> mechanism
> >
> > > to
> >
> > > > >> > support
> >
> > > > >> > >>> > > anyway.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > >
> https://tools.ietf.org/html/
> >
> > > > rfc7677
> >
> > > > >> > >>> > describes
> >
> > > > >> > >>> > > > the
> >
> > > > >> > >>> > > > > > > > protocol
> >
> > > > >> > >>> > > > > > > > > >> for
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > SCRAM-SHA-256.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > On Tue, May 24, 2016 at 2:37
> > AM,
> >
> > > > Jun
> >
> > > > >> > Rao <
> >
> > > > >> > >>> > > > > > > > j...@confluent.io
> >
> > > > >> > >>> > > > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > Parth,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > Thanks for the
> explanation.
> > A
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > couple
> >
> > > > >> > of
> >
> > > > >> > >>> > more
> >
> > > > >> > >>> > > > > > > questions.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > 110. What does
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > getDelegationTokenAs
> >
> > > > >> > >>> mean?
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > 111. What's the typical
> rate
> >
> > > of
> >
> > > > >> > getting
> >
> > > > >> > >>> and
> >
> > > > >> > >>> > > > > > renewing
> >
> > > > >> > >>> > > > > > > > > >> delegation
> >
> > > > >> > >>> > > > > > > > > >> >> > > > tokens?
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > That may have an impact on
> >
> > > > whether
> >
> > > > >> > they
> >
> > > > >> > >>> > > should
> >
> > > > >> > >>> > > > be
> >
> > > > >> > >>> > > > > > > > > directed
> >
> > > > >> > >>> > > > > > > > > >> to the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > controller.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > Jun
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > On Mon, May 23, 2016 at
> 1:19
> >
> > > PM,
> >
> > > > >> > parth
> >
> > > > >> > >>> > > > > brahmbhatt <
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> brahmbhatt.pa...@gmail.com>
> >
> > > > wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Hi Jun,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Thanks for reviewing.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > * We could add a Cluster
> >
> > > > action
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > to
> >
> > > > >> > add
> >
> > > > >> > >>> > acls
> >
> > > > >> > >>> > > > on
> >
> > > > >> > >>> > > > > > who
> >
> > > > >> > >>> > > > > > > > can
> >
> > > > >> > >>> > > > > > > > > >> request
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > delegation
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > tokens. I don't see the
> > use
> >
> > > > case
> >
> > > > >> > for
> >
> > > > >> > >>> that
> >
> > > > >> > >>> > > yet
> >
> > > > >> > >>> > > > > but
> >
> > > > >> > >>> > > > > > > > down
> >
> > > > >> > >>> > > > > > > > > >> the line
> >
> > > > >> > >>> > > > > > > > > >> >> > > > when
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > we
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > start supporting
> >
> > > > >> > getDelegationTokenAs
> >
> > > > >> > >>> it
> >
> > > > >> > >>> > > will
> >
> > > > >> > >>> > > > > be
> >
> > > > >> > >>> > > > > > > > > >> necessary.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > * Yes we recommend
> tokens
> > to
> >
> > > > be
> >
> > > > >> > only
> >
> > > > >> > >>> > > > > > > used/distributed
> >
> > > > >> > >>> > > > > > > > > >> over
> >
> > > > >> > >>> > > > > > > > > >> >> > secure
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > channels.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > * Depending on what
> design
> >
> > > we
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > end
> >
> > > > >> > up
> >
> > > > >> > >>> > > choosing
> >
> > > > >> > >>> > > > > > > > > >> Invalidation will
> >
> > > > >> > >>> > > > > > > > > >> >> > > be
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > responsibility of every
> >
> > > broker
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > or
> >
> > > > >> > >>> > > controller.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > * I am not sure if I
> >
> > > > documented
> >
> > > > >> > >>> somewhere
> >
> > > > >> > >>> > > > that
> >
> > > > >> > >>> > > > > > > > > >> invalidation
> >
> > > > >> > >>> > > > > > > > > >> >> > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > directly
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > go through zookeeper but
> >
> > > that
> >
> > > > is
> >
> > > > >> > not
> >
> > > > >> > >>> the
> >
> > > > >> > >>> > > > > intent.
> >
> > > > >> > >>> > > > > > > > > >> Invalidation
> >
> > > > >> > >>> > > > > > > > > >> >> > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > either
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > be request based or due
> to
> >
> > > > >> > >>> expiration. No
> >
> > > > >> > >>> > > > > direct
> >
> > > > >> > >>> > > > > > > > > >> zookeeper
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > interaction
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > from
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > any client.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > * "Broker also stores
> the
> >
> > > > >> > >>> DelegationToken
> >
> > > > >> > >>> > > > > without
> >
> > > > >> > >>> > > > > > > the
> >
> > > > >> > >>> > > > > > > > > >> hmac in
> >
> > > > >> > >>> > > > > > > > > >> >> > the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > zookeeper." : Sorry
> about
> >
> > > the
> >
> > > > >> > >>> confusion.
> >
> > > > >> > >>> > > The
> >
> > > > >> > >>> > > > > sole
> >
> > > > >> > >>> > > > > > > > > >> purpose of
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > zookeeper
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > in
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > this design is as
> >
> > > distribution
> >
> > > > >> > channel
> >
> > > > >> > >>> > for
> >
> > > > >> > >>> > > > > tokens
> >
> > > > >> > >>> > > > > > > > > >> between all
> >
> > > > >> > >>> > > > > > > > > >> >> > > > brokers
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > and a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > layer that ensures only
> >
> > > tokens
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > that
> >
> > > > >> > >>> were
> >
> > > > >> > >>> > > > > > generated
> >
> > > > >> > >>> > > > > > > by
> >
> > > > >> > >>> > > > > > > > > >> making a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > request
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > to a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > broker will be accepted
> >
> > > (more
> >
> > > > on
> >
> > > > >> > this
> >
> > > > >> > >>> in
> >
> > > > >> > >>> > > > second
> >
> > > > >> > >>> > > > > > > > > >> paragraph). The
> >
> > > > >> > >>> > > > > > > > > >> >> > > > token
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > consists of few elements
> >
> > > > (owner,
> >
> > > > >> > >>> renewer,
> >
> > > > >> > >>> > > > uuid
> >
> > > > >> > >>> > > > > ,
> >
> > > > >> > >>> > > > > > > > > >> expiration,
> >
> > > > >> > >>> > > > > > > > > >> >> > > hmac)
> >
> > > > >> > >>> > > > > > > > > >> >> > > > ,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > one
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > of
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > which is the finally
> >
> > > generated
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > hmac
> >
> > > > >> > >>> but
> >
> > > > >> > >>> > > hmac
> >
> > > > >> > >>> > > > it
> >
> > > > >> > >>> > > > > > > self
> >
> > > > >> > >>> > > > > > > > is
> >
> > > > >> > >>> > > > > > > > > >> >> > derivable
> >
> > > > >> > >>> > > > > > > > > >> >> > > > if
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > you
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > have all the other
> > elements
> >
> > > of
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > the
> >
> > > > >> > >>> token
> >
> > > > >> > >>> > +
> >
> > > > >> > >>> > > > > secret
> >
> > > > >> > >>> > > > > > > key
> >
> > > > >> > >>> > > > > > > > > to
> >
> > > > >> > >>> > > > > > > > > >> >> > generate
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > hmac.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Given zookeeper does not
> >
> > > > provide
> >
> > > > >> > SSL
> >
> > > > >> > >>> > > support
> >
> > > > >> > >>> > > > we
> >
> > > > >> > >>> > > > > > do
> >
> > > > >> > >>> > > > > > > > not
> >
> > > > >> > >>> > > > > > > > > >> want the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > entire
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > token to be wire
> > transferred
> >
> > > > to
> >
> > > > >> > >>> zookeeper
> >
> > > > >> > >>> > > as
> >
> > > > >> > >>> > > > > that
> >
> > > > >> > >>> > > > > > > > will
> >
> > > > >> > >>> > > > > > > > > >> be an
> >
> > > > >> > >>> > > > > > > > > >> >> > > > insecure
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > wire
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > transfer. Instead we
> only
> >
> > > > store
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > all
> >
> > > > >> > >>> the
> >
> > > > >> > >>> > > other
> >
> > > > >> > >>> > > > > > > > elements
> >
> > > > >> > >>> > > > > > > > > >> of a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > delegation
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > tokens. Brokers can read
> >
> > > these
> >
> > > > >> > >>> elements
> >
> > > > >> > >>> > and
> >
> > > > >> > >>> > > > > > because
> >
> > > > >> > >>> > > > > > > > > they
> >
> > > > >> > >>> > > > > > > > > >> also
> >
> > > > >> > >>> > > > > > > > > >> >> > > have
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > access
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > to secret key they will
> be
> >
> > > > able
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > to
> >
> > > > >> > >>> > generate
> >
> > > > >> > >>> > > > > hmac
> >
> > > > >> > >>> > > > > > on
> >
> > > > >> > >>> > > > > > > > > >> their end.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > One of the alternative
> >
> > > > proposed
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > is
> >
> > > > >> > to
> >
> > > > >> > >>> > avoid
> >
> > > > >> > >>> > > > > > > zookeeper
> >
> > > > >> > >>> > > > > > > > > >> >> > > altogether. A
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > Client
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > will call broker with
> >
> > > required
> >
> > > > >> > >>> > information
> >
> > > > >> > >>> > > > > > (owner,
> >
> > > > >> > >>> > > > > > > > > >> renwer,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > expiration)
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > and
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > get back (signed hmac,
> >
> > > uuid).
> >
> > > > >> > Broker
> >
> > > > >> > >>> > won't
> >
> > > > >> > >>> > > > > store
> >
> > > > >> > >>> > > > > > > this
> >
> > > > >> > >>> > > > > > > > > in
> >
> > > > >> > >>> > > > > > > > > >> >> > > zookeeper.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > From
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > this point a client can
> >
> > > > contact
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > any
> >
> > > > >> > >>> > broker
> >
> > > > >> > >>> > > > with
> >
> > > > >> > >>> > > > > > all
> >
> > > > >> > >>> > > > > > > > the
> >
> > > > >> > >>> > > > > > > > > >> >> > > delegation
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > token
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > info (owner, rewner,
> >
> > > > expiration,
> >
> > > > >> > hmac,
> >
> > > > >> > >>> > > uuid)
> >
> > > > >> > >>> > > > > the
> >
> > > > >> > >>> > > > > > > > borker
> >
> > > > >> > >>> > > > > > > > > >> will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > regenerate
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > hmac and as long as it
> >
> > > matches
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > with
> >
> > > > >> > >>> hmac
> >
> > > > >> > >>> > > > > > presented
> >
> > > > >> > >>> > > > > > > by
> >
> > > > >> > >>> > > > > > > > > >> client ,
> >
> > > > >> > >>> > > > > > > > > >> >> > > > broker
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > allow the request to
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > authenticate.
> >
> > > > >> > >>> Only
> >
> > > > >> > >>> > > > > problem
> >
> > > > >> > >>> > > > > > > with
> >
> > > > >> > >>> > > > > > > > > >> this
> >
> > > > >> > >>> > > > > > > > > >> >> > > approach
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > is
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > if
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > the secret key is
> >
> > > compromised
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > any
> >
> > > > >> > >>> client
> >
> > > > >> > >>> > > can
> >
> > > > >> > >>> > > > > now
> >
> > > > >> > >>> > > > > > > > > generate
> >
> > > > >> > >>> > > > > > > > > >> >> > random
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > tokens
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > and
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > they will still be able
> to
> >
> > > > >> > >>> authenticate
> >
> > > > >> > >>> > as
> >
> > > > >> > >>> > > > any
> >
> > > > >> > >>> > > > > > user
> >
> > > > >> > >>> > > > > > > > > they
> >
> > > > >> > >>> > > > > > > > > >> like.
> >
> > > > >> > >>> > > > > > > > > >> >> > > with
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > zookeeper we guarantee
> > that
> >
> > > > only
> >
> > > > >> > >>> tokens
> >
> > > > >> > >>> > > > > acquired
> >
> > > > >> > >>> > > > > > > via
> >
> > > > >> > >>> > > > > > > > a
> >
> > > > >> > >>> > > > > > > > > >> broker
> >
> > > > >> > >>> > > > > > > > > >> >> > > > (using
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > some
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > auth scheme other than
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > delegation
> >
> > > > >> > >>> token)
> >
> > > > >> > >>> > > will
> >
> > > > >> > >>> > > > > be
> >
> > > > >> > >>> > > > > > > > > >> accepted. We
> >
> > > > >> > >>> > > > > > > > > >> >> > > need
> >
> > > > >> > >>> > > > > > > > > >> >> > > > to
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > discuss which proposal
> > makes
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > more
> >
> > > > >> > >>> sense
> >
> > > > >> > >>> > and
> >
> > > > >> > >>> > > > we
> >
> > > > >> > >>> > > > > > can
> >
> > > > >> > >>> > > > > > > go
> >
> > > > >> > >>> > > > > > > > > >> over it
> >
> > > > >> > >>> > > > > > > > > >> >> > in
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > tomorrow's
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > meeting.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Also, can you forward
> the
> >
> > > > invite
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > to
> >
> > > > >> > >>> me?
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Thanks
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > Parth
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > On Mon, May 23, 2016 at
> >
> > > 10:35
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > AM,
> >
> > > > >> > Jun
> >
> > > > >> > >>> > Rao <
> >
> > > > >> > >>> > > > > > > > > >> j...@confluent.io>
> >
> > > > >> > >>> > > > > > > > > >> >> > > > wrote:
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > Thanks for the KIP. A
> > few
> >
> > > > >> > comments.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > 100. This potentially
> > can
> >
> > > be
> >
> > > > >> > useful
> >
> > > > >> > >>> for
> >
> > > > >> > >>> > > > Kafka
> >
> > > > >> > >>> > > > > > > > Connect
> >
> > > > >> > >>> > > > > > > > > >> and
> >
> > > > >> > >>> > > > > > > > > >> >> > Kafka
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > rest
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > proxy
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > where a worker agent
> > will
> >
> > > > need
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > to
> >
> > > > >> > >>> run a
> >
> > > > >> > >>> > > > task
> >
> > > > >> > >>> > > > > on
> >
> > > > >> > >>> > > > > > > > > behalf
> >
> > > > >> > >>> > > > > > > > > >> of a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > client.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > We
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > likely need to change
> > how
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > those
> >
> > > > >> > >>> > services
> >
> > > > >> > >>> > > > use
> >
> > > > >> > >>> > > > > > > Kafka
> >
> > > > >> > >>> > > > > > > > > >> clients
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > (producer/consumer).
> >
> > > Instead
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > of a
> >
> > > > >> > >>> > shared
> >
> > > > >> > >>> > > > > client
> >
> > > > >> > >>> > > > > > > per
> >
> > > > >> > >>> > > > > > > > > >> worker,
> >
> > > > >> > >>> > > > > > > > > >> >> > we
> >
> > > > >> > >>> > > > > > > > > >> >> > > > will
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > need
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > a
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > client per user task
> > since
> >
> > > > the
> >
> > > > >> > >>> > > > authentication
> >
> > > > >> > >>> > > > > > > > happens
> >
> > > > >> > >>> > > > > > > > > >> at the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > connection
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > level. For Kafka
> > Connect,
> >
> > > > the
> >
> > > > >> > >>> renewer
> >
> > > > >> > >>> > > will
> >
> > > > >> > >>> > > > be
> >
> > > > >> > >>> > > > > > the
> >
> > > > >> > >>> > > > > > > > > >> workers.
> >
> > > > >> > >>> > > > > > > > > >> >> > So,
> >
> > > > >> > >>> > > > > > > > > >> >> > > we
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > probably
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > need to allow multiple
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > renewers.
> >
> > > > >> > For
> >
> > > > >> > >>> > > Kafka
> >
> > > > >> > >>> > > > > rest
> >
> > > > >> > >>> > > > > > > > > proxy,
> >
> > > > >> > >>> > > > > > > > > >> the
> >
> > > > >> > >>> > > > > > > > > >> >> > > > renewer
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > can
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > probably just be the
> >
> > > creator
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > of
> >
> > > > >> > the
> >
> > > > >> > >>> > > token.
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > 101. Do we need new
> acl
> > on
> >
> > > > who
> >
> > > > >> > can
> >
> > > > >> > >>> > > request
> >
> > > > >> > >>> > > > > > > > delegation
> >
> > > > >> > >>> > > > > > > > > >> tokens?
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > >
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > 102. Do we recommend
> >
> > > people
> >
> > > > to
> >
> > > > >> > send
> >
> > > > >> > >>> > > > > delegation
> >
> > > > >> > >>> > > > > > > > tokens
> >
> > > > >> > >>> > > > > > > > > >> in an
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > encrypted
> >
> > > > >> > >>> > > > > > > > > >> >> > > > > > > > > channel?
> >
> > > > >> > >>>
>
