kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Rao <...@confluent.io>
Subject Re: [VOTE] KIP-48 Support for delegation tokens as an authentication mechanism
Date Wed, 08 Feb 2017 22:04:36 GMT
Hi, Mani,

Thanks for the responses. A few more comments.

101.2/101.3. Could we just remove owner and renewer from
DelegationTokenResponse if we don't have a use case?

111. ExpireTokenResponse: Should we return the new expiration time in the
response?

112. DescribeTokenRequest: A common use case is probably to see a list of
tokens associated with a particular owner. Would it be useful to include a
list of owners in the request? We can use the same convention in other
requests such that if the list is set to null (i.e., length is -1), return
all tokens.

113. delegation.token.master.key: It seems that needs to be the same across
brokers? Perhaps we can mention that in the wiki.

114. Could we document the procedure of manually rotating the secret? Does
one have to do sth like: expire all existing tokens, rotate the secret, and
generate new tokens?

115. Could we also include in the command line the ability to describe
tokens?

116. Could you document the ACL rules associated with those new requests?
For example, do we allow any one to create, delete, describe delegation
tokens?

Thanks,

Jun


On Wed, Feb 8, 2017 at 1:35 AM, Manikumar <manikumar.reddy@gmail.com> wrote:

> Hi Jun,
>
>
> > If a token expires, then every broker will potentially try to delete it
> > around the same time, but only one will succeed. So, we will have to deal
> > with failures in that case? Another way is to let just one broker (say,
> the
> > controller) deletes expired tokens.
> >
> >
>  Agree, we can run the token expiry check thread as part of controller
> broker.
>  WIll update the KIP.
>
>
> Thanks,
> Manikumar
>
>
> >
> > On Sun, Feb 5, 2017 at 9:54 AM, Manikumar <manikumar.reddy@gmail.com>
> > wrote:
> >
> > > Hi Jun,
> > >
> > >  Please see the replies inline.
> > >
> > >
> > > > >
> > > > > Only one broker does the deletion. Broker updates the expiration
in
> > its
> > > > > local cache
> > > > > and on zookeeper so other brokers also get notified and their cache
> > > > > statuses are updated as well.
> > > > >
> > > > >
> > > > Which broker does the deletion?
> > > >
> > >
> > > Any broker can handle the create/expire/renew/describe delegationtoken
> > > requests.
> > > changes are propagated through zk notifications.  Every broker is
> > > responsible for
> > > expiring the tokens. This check be can done during request handling
> time
> > > and/or
> > > during token authentication time.
> > >
> > >
> > > >
> > > >
> > > > 110. The diagrams in the wiki still show MD5 digest. Could you change
> > it
> > > to
> > > > SCRAM?
> > > >
> > > >
> > >   Updated the diagram.
> > >
> > >
> > >
> > > Thanks,
> > > Manikumar
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > Thanks.
> > > > > Manikumar
> > > > >
> > > > >
> > > > > >
> > > > > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar <
> > > manikumar.reddy@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I would like to initiate the vote on KIP-48:
> > > > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+
> > > > > > > Delegation+token+support+for+Kafka
> > > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Manikumar
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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