Thinking out loud here:
It looks like authentication with a delegation token is going to be
super-cheap, right? We just compare the token to a value in the broker
cache?
If I understood the KIP correctly, right now it suggests that
authentication happens when establishing the client-broker connection (as
normal for Kafka. But perhaps we want to consider authenticating every
request with delegation token (if exists)?
So a centralized app can create few producers, do the metadata request and
broker discovery with its own user auth, but then use delegation tokens to
allow performing produce/fetch requests as different users? Instead of
having to re-connect for each impersonated user?
This may over-complicate things quite a bit (basically adding extra
information in every request), but maybe it will be useful for
impersonation use-cases (which seem to drive much of the interest in this
KIP)?
Kafka Connect, NiFi and friends can probably use this to share clients
between multiple jobs, tasks, etc.
What do you think?
Gwen
On Tue, Dec 13, 2016 at 12:43 AM, Manikumar <manikumar.re...@gmail.com>
wrote:
> Ashish,
>
> Thank you for reviewing the KIP. Please see the replies inline.
>
>
> > 1. How to disable delegation token authentication?
> >
> > This can be achieved in various ways, however I think reusing delegation
> > token secret config for this makes sense here. Avoids creating yet
> another
> > config and forces delegation token users to consciously set the secret.
> If
> > the secret is not set or set to empty string, brokers should turn off
> > delegation token support. This will however require a new error code to
> > indicate delegation token support is turned off on broker.
> >
>
> Thanks for the suggestion. Option to turnoff delegation token
> authentication will be useful.
> I'll update the KIP.
>
>
> >
> > 2. ACLs on delegation token?
> >
> > Do we need to have ACLs defined for tokens? I do not think it buys us
> > anything, as delegation token can be treated as impersonation of the
> owner.
> > Any thing the owner has permission to do, delegation tokens should be
> > allowed to do as well. If so, we probably won't need to return
> > authorization exception error code while creating delegation token. It
> > however would make sense to check renew and expire requests are coming
> from
> > owner or renewers of the token, but that does not require explicit acls.
> >
>
>
> Yes, We agreed to not have new acl on who can request delegation token.
> I'll update the KIP.
>
>
> >
> > 3. How to restrict max life time of a token?
> >
> > Admins might want to restrict max life time of tokens created on a
> cluster,
> > and this can very from cluster to cluster based on use-cases. This might
> > warrant a separate broker config.
> >
> >
> Currently we have "delegation.token.max.lifetime.sec" server config
> property
> May be we can take min(User supplied MaxTime, Server MaxTime) as max life
> time.
> I am open to add new config property.
>
> Few more comments based on recent KIP update.
> >
> > 1. Do we need a separate {{InvalidateTokenRequest}}? Can't we use
> > {{ExpireTokenRequest}} with with expiryDate set to anything before
> current
> > date?
> >
>
> makes sense. we don't need special request to cancel the token. We can use
> ExpireTokenRequest.
> I'll update the KIP.
>
>
> > 2. Can we change time field names to indicate their unit is milliseconds,
> > like, IssueDateMs, ExpiryDateMs, etc.?
> >
> >
> Done.
>
>
> > 3. Can we allow users to renew a token for a specified amount of time? In
> > current version of KIP, renew request does not take time as a param, not
> > sure what is expiry time set to after renewal.
> >
> >
> Yes, we need to specify renew period. I'll update the KIP.
>
>
> Thanks,
> Mankumar
>
>
>
> >
> > On Mon, Dec 12, 2016 at 9:08 AM Manikumar <manikumar.re...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I would like to reinitiate the discussion on Delegation token support
> for
> > >
> > > Kafka.
> > >
> > >
> > >
> > > Brief summary of the past discussion:
> > >
> > >
> > >
> > > 1) Broker stores delegation tokens in zookeeper. All brokers will
> have a
> > >
> > > cache backed by
> > >
> > > zookeeper so they will all get notified whenever a new token is
> > >
> > > generated and they will
> > >
> > > update their local cache whenever token state changes.
> > >
> > > 2) The current proposal does not support rotation of secret
> > >
> > > 3) Only allow the renewal by users that authenticated using *non*
> > >
> > > delegation token mechanism
> > >
> > > 4) KIP-84 proposes to support SASL SCRAM mechanisms. Kafka clients can
> > >
> > > authenticate using
> > >
> > > SCRAM-SHA-256, providing the delegation token HMAC as password.
> > >
> > >
> > >
> > > Updated the KIP with the following:
> > >
> > > 1. Protocol and Config changes
> > >
> > > 2. format of the data stored in ZK.
> > >
> > > 3. Changes to Java Clients/Usage of SASL SCRAM mechanism
> > >
> > >
> > >
> > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> > >
> > > 48+Delegation+token+support+for+Kafka
> > >
> > >
> > >
> > >
> > >
> > > Jun, Ashish, Gwen,
> > >
> > >
> > >
> > > Pl review the updated KIP.
> > >
> > >
> > >
> > > Thanks
> > >
> > > Manikumar
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Sep 29, 2016 at 9:56 PM, Ashish Singh <asi...@cloudera.com>
> > wrote:
> > >
> > >
> > >
> > > > Harsha/ Gwen,
> > >
> > > >
> > >
> > > > How do we proceed here? I am willing to help out with here.
> > >
> > > >
> > >
> > > > On Fri, Sep 23, 2016 at 11:41 AM, Gwen Shapira <g...@confluent.io>
> > > wrote:
> > >
> > > >
> > >
> > > > > Is it updated? are all concerns addressed? do you want to start a
> > vote?
> > >
> > > > >
> > >
> > > > > Sorry for being pushy, I do appreciate that we are all volunteers
> and
> > >
> > > > > finding time is difficult. This feature is important for anything
> > that
> > >
> > > > > integrates with Kafka (stream processors, Flume, NiFi, etc) and I
> > >
> > > > > don't want to see this getting stuck because we lack coordination
> > >
> > > > > within the community.
> > >
> > > > >
> > >
> > > > > On Thu, Sep 15, 2016 at 6:39 PM, Harsha Chintalapani <
> > ka...@harsha.io>
> > >
> > > > > wrote:
> > >
> > > > > > The only pending update for the KIP is to write up the protocol
> > > changes
> > >
> > > > > like
> > >
> > > > > > we've it KIP-4. I'll update the wiki.
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > On Thu, Sep 15, 2016 at 4:27 PM Ashish Singh <
> asi...@cloudera.com>
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >> I think we decided to not support secret rotation, I guess this
> > can
> > > be
> > >
> > > > > >> stated clearly on the KIP. Also, more details on how clients
> will
> > >
> > > > > perform
> > >
> > > > > >> token distribution and how CLI will look like will be helpful.
> > >
> > > > > >>
> > >
> > > > > >> On Thu, Sep 15, 2016 at 3:20 PM, Gwen Shapira <
> g...@confluent.io>
> > >
> > > > > wrote:
> > >
> > > > > >>
> > >
> > > > > >> > Hi Guys,
> > >
> > > > > >> >
> > >
> > > > > >> > This discussion was dead for a while. Are there still
> > contentious
> > >
> > > > > >> > points? If not, why are there no votes?
> > >
> > > > > >> >
> > >
> > > > > >> > On Tue, Aug 23, 2016 at 1:26 PM, Jun Rao <j...@confluent.io>
> > > wrote:
> > >
> > > > > >> > > Ashish,
> > >
> > > > > >> > >
> > >
> > > > > >> > > Yes, I will send out a KIP invite for next week to discuss
> > > KIP-48
> > >
> > > > > and
> > >
> > > > > >> > other
> > >
> > > > > >> > > remaining KIPs.
> > >
> > > > > >> > >
> > >
> > > > > >> > > Thanks,
> > >
> > > > > >> > >
> > >
> > > > > >> > > Jun
> > >
> > > > > >> > >
> > >
> > > > > >> > > On Tue, Aug 23, 2016 at 1:22 PM, Ashish Singh <
> > >
> > > > asi...@cloudera.com>
> > >
> > > > > >> > wrote:
> > >
> > > > > >> > >
> > >
> > > > > >> > >> Thanks Harsha!
> > >
> > > > > >> > >>
> > >
> > > > > >> > >> Jun, can we add KIP-48 to next KIP hangout's agenda. Also,
> we
> > > did
> > >
> > > > > not
> > >
> > > > > >> > >> actually make a call on when we should have next KIP call.
> As
> > >
> > > > there
> > >
> > > > > >> > >> are
> > >
> > > > > >> > a
> > >
> > > > > >> > >> few outstanding KIPs that could not be discussed this week,
> > can
> > >
> > > > we
> > >
> > > > > >> > >> have
> > >
> > > > > >> > a
> > >
> > > > > >> > >> KIP hangout call next week?
> > >
> > > > > >> > >>
> > >
> > > > > >> > >> On Tue, Aug 23, 2016 at 1:10 PM, Harsha Chintalapani
> > >
> > > > > >> > >> <ka...@harsha.io>
> > >
> > > > > >> > >> wrote:
> > >
> > > > > >> > >>
> > >
> > > > > >> > >>> Ashish,
> > >
> > > > > >> > >>> Yes we are working on it. Lets discuss in the next
> > KIP
> > >
> > > > > >> > >>> meeting.
> > >
> > > > > >> > >>> I'll join.
> > >
> > > > > >> > >>> -Harsha
> > >
> > > > > >> > >>>
> > >
> > > > > >> > >>> On Tue, Aug 23, 2016 at 12:07 PM Ashish Singh <
> > >
> > > > > asi...@cloudera.com>
> > >
> > > > > >> > >>> wrote:
> > >
> > > > > >> > >>>
> > >
> > > > > >> > >>> > Hello Harsha,
> > >
> > > > > >> > >>> >
> > >
> > > > > >> > >>> > Are you still working on this? Wondering if we can
> discuss
> > >
> > > > this
> > >
> > > > > in
> > >
> > > > > >> > next
> > >
> > > > > >> > >>> KIP
> > >
> > > > > >> > >>> > meeting, if you can join.
> > >
> > > > > >> > >>> >
> > >
> > > > > >> > >>> > On Mon, Jul 18, 2016 at 9:51 AM, Harsha Chintalapani <
> > >
> > > > > >> > ka...@harsha.io>
> > >
> > > > > >> > >>> > wrote:
> > >
> > > > > >> > >>> >
> > >
> > > > > >> > >>> > > Hi Grant,
> > >
> > > > > >> > >>> > > We are working on it. Will add the details
> to
> > > KIP
> > >
> > > > > >> > >>> > > about
> > >
> > > > > >> > the
> > >
> > > > > >> > >>> > > request protocol.
> > >
> > > > > >> > >>> > >
> > >
> > > > > >> > >>> > > Thanks,
> > >
> > > > > >> > >>> > > Harsha
> > >
> > > > > >> > >>> > >
> > >
> > > > > >> > >>> > > On Mon, Jul 18, 2016 at 6:50 AM Grant Henke
> > >
> > > > > >> > >>> > > <ghe...@cloudera.com>
> > >
> > > > > >> > >>> wrote:
> > >
> > > > > >> > >>> > >
> > >
> > > > > >> > >>> > > > Hi Parth,
> > >
> > > > > >> > >>> > > >
> > >
> > > > > >> > >>> > > > Are you still working on this? If you need any help
> > > please
> > >
> > > > > >> > >>> > > > don't
> > >
> > > > > >> > >>> > hesitate
> > >
> > > > > >> > >>> > > > to ask.
> > >
> > > > > >> > >>> > > >
> > >
> > > > > >> > >>> > > > Thanks,
> > >
> > > > > >> > >>> > > > Grant
> > >
> > > > > >> > >>> > > >
> > >
> > > > > >> > >>> > > > On Thu, Jun 30, 2016 at 4:35 PM, Jun Rao <
> > >
> > > > j...@confluent.io>
> > >
> > > > > >> > wrote:
> > >
> > > > > >> > >>> > > >
> > >
> > > > > >> > >>> > > > > Parth,
> > >
> > > > > >> > >>> > > > >
> > >
> > > > > >> > >>> > > > > Thanks for the reply.
> > >
> > > > > >> > >>> > > > >
> > >
> > > > > >> > >>> > > > > It makes sense to only allow the renewal by users
> > that
> > >
> > > > > >> > >>> authenticated
> > >
> > > > > >> > >>> > > > using
> > >
> > > > > >> > >>> > > > > *non* delegation token mechanism. Then, should we
> > make
> > >
> > > > the
> > >
> > > > > >> > >>> renewal a
> > >
> > > > > >> > >>> > > > list?
> > >
> > > > > >> > >>> > > > > For example, in the case of rest proxy, it will be
> > >
> > > > useful
> > >
> > > > > >> > >>> > > > > for
> > >
> > > > > >> > >>> every
> > >
> > > > > >> > >>> > > > > instance of rest proxy to be able to renew the
> > tokens.
> > >
> > > > > >> > >>> > > > >
> > >
> > > > > >> > >>> > > > > It would be clearer if we can document the request
> > >
> > > > > protocol
> > >
> > > > > >> > like
> > >
> > > > > >> > >>> > > > >
> > >
> > > > > >> > >>> > > > >
> > >
> > > > > >> > >>> > > > https://cwiki.apache.org/confl
> > uence/display/KAFKA/KIP-
> > >
> > > > > >> > >>> > >
> > >
> > > > > >> > >>> > > 4+-+Command+line+and+centralized+administrative+
> > >
> > > > > operations#KIP-4-
> > >
> > > > > >> > >>> > > 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?
> > >
> > > > > >> > >>>
> >
>
--
*Gwen Shapira*
Product Manager | Confluent
650.450.2760 | @gwenshap
Follow us: Twitter <https://twitter.com/ConfluentInc> | blog
<http://www.confluent.io/blog>
