Thank you all for your votes and feedback.
The vote has passed with 4 binding votes(Gwen, Jun, Grant, Harsha) and 2
non-binding votes(Roger, Dong Lin).
I have updated the relevant wiki pages.
Thanks
Manikumar
On Tue, Feb 14, 2017 at 12:02 AM, Dong Lin wrote:
> +1 (non-binding)
>
> On Mon, Feb
+1 (non-binding)
On Mon, Feb 13, 2017 at 10:21 AM, Harsha Chintalapani
wrote:
> +1.
> -Harsha
>
> On Fri, Feb 10, 2017 at 11:12 PM Manikumar
> wrote:
>
> > Yes, owners and the renewers can always describe their own tokens.
> Updated
> > the KIP.
> >
> > On Sat, Feb 11, 2017 at 3:12 AM, Jun Rao
+1.
-Harsha
On Fri, Feb 10, 2017 at 11:12 PM Manikumar
wrote:
> Yes, owners and the renewers can always describe their own tokens. Updated
> the KIP.
>
> On Sat, Feb 11, 2017 at 3:12 AM, Jun Rao wrote:
>
> > Hi, Mani,
> >
> > Thanks for the update. Just a minor comment below. Otherwise, +1 from
Yes, owners and the renewers can always describe their own tokens. Updated
the KIP.
On Sat, Feb 11, 2017 at 3:12 AM, Jun Rao wrote:
> Hi, Mani,
>
> Thanks for the update. Just a minor comment below. Otherwise, +1 from me.
>
>
> >
> > >
> > > 116. Could you document the ACL rules associated with
Hi, Mani,
Thanks for the update. Just a minor comment below. Otherwise, +1 from me.
>
> >
> > 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?
> >
> >
> Currently we only allow a owne
Hi Jun,
Thanks for the detailed review. Pl see the replies inline
> 101.2/101.3. Could we just remove owner and renewer from
> DelegationTokenResponse if we don't have a use case?
>
>
Removed owner/renewer fileds from DelegationTokenResponse. Updated the KIP.
> 111. ExpireTokenResponse: Should
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
Thanks. I found the other discussion thread. Sorry for being behind on
this.
I'm interested in the future impersonation use cases. This seems to get us
closer.
+1 (non-binding)
On Wed, Feb 8, 2017 at 4:41 AM, Manikumar wrote:
> Hi Roger,
>
> In the current proposal, we only allow a user to
Hi Jason,
As noticed by you, the current proposal does not support rotation of secret.
We also discussed about maintaining a list of secret keys. Other option
could
be using the controller to generate and rotate secret and distribute it to
all brokers.
I will update the possible alternatives to fu
Hi Roger,
In the current proposal, we only allow a user to get delegation token for
that user only.
Anyone who gets that token can impersonate the user on the broker.
Yes, In future we can extend the support to allow a user to acquire
delegation tokens for
other users.
Pl refer discuss mail thre
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
Hi Jun,
How does it allow impersonation at the connection level? Looking at the
KIP, the DelegationTokenRequest does not have an "Owner" field that can be
set. The owner field of the DelegationTokenResponse says it's the "Kakfa
Principal which requested the delegation token". For impersonation
Hi, Roger,
Just to clarify. This KIP already allows you to do impersonation at the
connection level. Are you talking about impersonation at the request level?
Thanks,
Jun
On Tue, Feb 7, 2017 at 5:53 PM, Roger Hoover wrote:
> Just wondering...how difficult would be it be to later add impersona
Just wondering...how difficult would be it be to later add impersonation (
https://issues.apache.org/jira/browse/KAFKA-3712)? One use case would be a
Kafka admin UI that would take action on the cluster on behalf different
users.I suppose we could later add an "effectiveUserId" (in Unix
termin
+1 from me as well.
On Tue, Feb 7, 2017 at 7:10 PM, Jason Gustafson wrote:
> Looks like a great proposal! I noticed that key rotation is not included.
> That may be reasonable for the initial work, but it might be nice to share
> some thoughts on how that might work in the future. For example, I
Looks like a great proposal! I noticed that key rotation is not included.
That may be reasonable for the initial work, but it might be nice to share
some thoughts on how that might work in the future. For example, I could
imagine delegation.token.master.key could be a list, which would allow
users
Read the KIP again and I think it looks good.
+1 from me.
On Tue, Feb 7, 2017 at 3:05 PM, Jun Rao wrote:
> Hi, Mani,
>
> 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 cas
Hi, Mani,
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.
It would also be helpful for
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 broke
Hi, Mani,
Sorry for the late response. A couple of more comments below.
> 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 ca
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
Hi, Mani
Thanks for the proposal. Looks good at the high level. A few comments
below.
101. DelegationTokenRequest/DelegationTokenResponse
101.1 I am wondering if renewer should be principalType + name to match
what we have in kafka-acls tool?
101.2 Do we need to return owner in DelegationTokenRe
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
23 matches
Mail list logo
