kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dong Lin <lindon...@gmail.com>
Subject Re: [VOTE] KIP-48 Support for delegation tokens as an authentication mechanism
Date Mon, 13 Feb 2017 18:32:41 GMT
+1 (non-binding)

On Mon, Feb 13, 2017 at 10:21 AM, Harsha Chintalapani <mail@harsha.io>
wrote:

> +1.
> -Harsha
>
> On Fri, Feb 10, 2017 at 11:12 PM Manikumar <manikumar.reddy@gmail.com>
> 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 <jun@confluent.io> 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 those new
> > > requests?
> > > > > For example, do we allow any one to create, delete, describe
> > delegation
> > > > > tokens?
> > > > >
> > > > >
> > > > Currently we only allow a owner to create delegation token for that
> > owner
> > > > only.
> > > > Any thing the owner has permission to do, delegation tokens should be
> > > > allowed to do as well. We can also check renew and expire requests
> are
> > > > coming
> > > > from owner or renewers of the token. So we may not need ACLs for
> > > > create/renew/expire requests.
> > > >
> > > > For describe, we can add DESCRIBE operation on TOKEN Resource. In
> > future,
> > > > when we extend
> > > > the support to allow a user to acquire delegation tokens for other
> > users,
> > > > then we can enable
> > > > CREATE/DELETE operations. Updated the KIP.
> > > >
> > > >
> > > This sounds good. I guess the owner and the renewer can always describe
> > > their own tokens?
> > >
> > > Jun
> > >
> >
>

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