Hi Jun,
Thanks for the review. Sorry for the delayed response. Please see the
replies inline.
> 101. DelegationTokenRequest/DelegationTokenResponse
> 101.1 I am wondering if renewer should be principalType + name to match
> what we have in kafka-acls tool?
>
Yes, renewer should be principalType + name. Will Update the KIP.
> 101.2 Do we need to return owner in DelegationTokenResponse?
> 101.3 Do we need to return renewer in DelegationTokenResponse?
>
>
The idea is to return complete token details. If there is no use, then we
can omit them.
@Ashish Since you are implementing this part of the KIP, Pl reply if
you have any concerns.
> 102. RenewDelegationTokenRequest/RenewDelegationTokenResponse
> 102.1 In RenewDelegationTokenRequest, is the renewal time bounded
> by delegation.token.expiry.time.sec ?
>
renewal time is bounded by delegation.token.max.lifetime.ms.
delegation.token.expiry.time.sec is used as default renew period. It will
be used to compute
expiryDate for first time and used if renew period is not provided in
RenewDelegationTokenRequest
token expiryDate = min(currentTime + renewPeriod, maxDate)
102.2 Do we need to include TokenDetails in RenewDelegationTokenResponse?
>
>
After renewal we are only updating token expiry time. So we may not need to
return
complete TokenDetails. Will Update the KIP.
> 103. Do we need a DescribeDelegationTokenRequest and a corresponding tool
> to list/describe existing delegation tokens?
>
>
Yes, we can add token describe request and tool. will update the KIP
> 104. KafkaConfig: Do we need a new config to disable/enable delegation
> tokens?
>
>
Currently we need masterKey (delegation.token.master.key config property)
to generate
delegation tokens. This masterKey needs to be configured with all the
brokers. If this config
property is not set, then brokers will disable the delegation token
support.
105. Could we be more consistent with the naming in configs, the request
> protocol fields and ZK structure with respect to time
> (e.g. delegation.token.max.lifetime.sec => delegation.token.max.lifetime.
> ms
> )?
>
>
All the time related configs/fileds changed to ms.
> 106. Using SASL SCRAM for delegation token
> 106.1 What should be set for username? Does it matter?
>
We will provide "tokenID(sequence number)" as username. This will uniquely
identifies the token.
> 106.2 Could you provide a bit more details on how to distinguish it from
> regular SASL SCRAM?
>
>
High level approach is given below:
On Client Side:
1. add a config property "tokenauth=true" to jass config. ScramLoginModule
loads this property if exists.
2. add this property to optional extension attributes of Scram
ClientFirstMessage.
On Server Side:
1. Update CredentialProvider class to handle tokenCredentialCache & add
TokenCredentialCallback
2. read the ClientFirstMessage
if tokenauth=true exists then
do token validations
get credentials from tokenCredentialCache
else
get credentials from regular CredentialCache
3. Continue Scram handshake
> 107. ZK structure
> 107.1 Could you provide more details on what SCRAM credentials are stored
> in ZK path /tokenauth/tokens/<tokenUID>?
>
We will store similar to regular scram credentials. These will get
generated during token creation.
Here we will use password=HMAC, iterations=4096 to generate credentials.
{
"version":1,
"owner" : "owner",
"renewer" : "renewer",
"issueDate" : "issueDate",
"tokenID" : "sequence-number",
//Store SCRAM credentials as per KIP-84
"credentials": {
"SCRAM-SHA-512" :
"salt=<Salt>,stored_key=<StoredKey>,server_key=<ServerKey>,iterations=<Iterations>",
"SCRAM-SHA-256" :
"salt=<Salt>,stored_key=<StoredKey>,server_key=<ServerKey>,iterations=<Iterations>
}
};
107.2 Do we need to somehow normalize tokeUID before using it
> in /tokenauth/tokens/<tokenUID> (e.g., what happens if tokenUUID includes
> '/')?
>
We will use a a sequence number as tokenUID. Will update the terminology
tokenUID => tokenID.
> 107.3 How does each broker know about changes in tokens? Does each broker
> register a watcher for /tokenauth/tokens?
>
Yes, the changes are updated through zk notifications.
> 107.4 How is token deletion handled? Does every broker delete the same
> token independently or only one broker does the deletion?
>
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.
Thanks.
Manikumar
>
> On Fri, Dec 23, 2016 at 9:26 AM, Manikumar <manikumar.re...@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
> >
>
