You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Manikumar <ma...@gmail.com> on 2018/09/25 16:26:35 UTC

[DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Hi all,

I have created a KIP that proposes to allow users to create delegation
tokens for other users.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users

Please take a look when you get a chance.

Thanks,
Manikumar

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Ryanne Dolan <ry...@gmail.com>.
+1 non-binding

Ryanne

On Tue, Sep 10, 2019, 7:51 AM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Bumping this in the hope I can get more feedback and/or votes.
>
> Thanks,
> Viktor
>
> On Tue, Sep 3, 2019 at 1:49 PM Gabor Somogyi <ga...@gmail.com>
> wrote:
>
> > +1 (non-binding) I've had a deeper look and this would be a good addition
> > to Spark.
> >
> >
> > On Thu, Aug 15, 2019 at 6:19 PM Viktor Somogyi-Vass <
> > viktorsomogyi@gmail.com>
> > wrote:
> >
> > > Started to implement my proposition and thought about it a little bit
> > more
> > > and it seems like I overthought the problem and we'd actually be better
> > off
> > > by having only the User resource type only and not CreateUsers. The
> > problem
> > > with CreateUsers is that a resource apparently is created only in
> addAcls
> > > (at least in SimpleAclAuthorizer). Therefore we'd need to check before
> > > creating the token that the owner user has been created and the token
> > > creator has the permissions. Then add the user resource and the token.
> > This
> > > means that we'd only use CreateUsers when creating tokens iff the token
> > > requester principal already has CreateTokens permissions with that user
> > > (the owner) so it's kinda duplicate.
> > > It would work though if we require the resources to be added beforehand
> > but
> > > it's not the case and is the detail of the Authorizer implementation.
> > >
> > > I'll update the KIP accordingly and apologies for the extra round :).
> > >
> > > Thanks,
> > > Viktor
> > >
> > > On Wed, Aug 14, 2019 at 2:40 PM Viktor Somogyi-Vass <
> > > viktorsomogyi@gmail.com>
> > > wrote:
> > >
> > > > Sorry, reading my email the second time I probably wasn't clear.
> > > > So basically the concept is that there is a user who can add other
> > users
> > > > as resources (such as userB and userC) prior to creating the "userA
> can
> > > > create delegation token for userB and userC" association with
> > > CreateTokens.
> > > > To limit who can add new users as resources I thought we can
> introduce
> > a
> > > > CreateUser operation. It's true though that we could also say that a
> > > Create
> > > > operation permission on the Cluster resource would be enough to
> create
> > > new
> > > > users but I think from a generic security perspective it's better if
> we
> > > > don't extend already existing operations.
> > > > So a classic flow would be that prior to creating the delegation
> token
> > > for
> > > > userB, userB itself has to be added by another user who has
> CreateUser
> > > > permissions. After this a CreateToken permission has to be created
> that
> > > > says "userA can create delegation tokens for userB" and after this
> > userA
> > > > can actually create the token.
> > > > Let me know what you think.
> > > >
> > > > Viktor
> > > >
> > > > On Wed, Aug 14, 2019 at 1:30 PM Manikumar <manikumar.reddy@gmail.com
> >
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Why do we need  new ACL operation  "CreateUsers"?
> > > >> I think,  "CreateTokens" Operation is sufficient to create "UserA
> can
> > > >> create tokens for UserB, UserC" association.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <
> > > >> viktorsomogyi@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi Manikumar,
> > > >> >
> > > >> > Yea, I just brought up superuser for the sake of simplicity :).
> > > >> > Anyway, your proposition makes sense to me, I'll modify the KIP
> for
> > > >> this.
> > > >> >
> > > >> > The changes summarized:
> > > >> > 1. We'll need a new ACL operation as well (say "CreateUsers") to
> > > create
> > > >> the
> > > >> > "UserA can create tokens for UserB, UserC" association. This can
> be
> > > used
> > > >> > via the createAcls API of the AdminClient.
> > > >> > 2. CreateToken will be a User level operation (instead of a
> Cluster
> > > >> level
> > > >> > as in previous drafts). So that means any user who wants to
> create a
> > > >> > delegation token for other users will have to have an ACL set up
> by
> > a
> > > >> > higher level user to authorize this.
> > > >> > 3. DescribeToken will also be a User level operation. In this case
> > > >> tokenT
> > > >> > owned by userB will be described if userA has a Describe ACL on
> > tokenT
> > > >> or
> > > >> > has a DescribeToken ACL on userB. Note that in the latter case
> userA
> > > >> will
> > > >> > be able to describe all other tokens belonging to userB.
> > > >> >
> > > >> > Would this work for you?
> > > >> >
> > > >> > Viktor
> > > >> >
> > > >> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org>
> > > >> wrote:
> > > >> >
> > > >> > > +1 for better access control here. In general, impersonating
> > another
> > > >> user
> > > >> > > seems like it’s equivalent to super user access.
> > > >> > >
> > > >> > > Colin
> > > >> > >
> > > >> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> > > >> > > > Hi Viktor,
> > > >> > > >
> > > >> > > > As per the KIP, It's not only superuser, any user with
> required
> > > >> > > permissions
> > > >> > > > (CreateTokens on Cluster Resource), can create the tokens for
> > > other
> > > >> > > users.
> > > >> > > > Current proposed permissions defined like, "UserA can create
> > > tokens
> > > >> for
> > > >> > > any
> > > >> > > > user".
> > > >> > > > I am thinking, can we change the permissions like "UserA can
> > > create
> > > >> > > tokens
> > > >> > > > for UserB, UserC"?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> > > >> > > viktorsomogyi@gmail.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Hey Manikumar,
> > > >> > > > >
> > > >> > > > > Thanks for the feedback.
> > > >> > > > > I'm not sure I fully grasp the use-case. Would this be a
> > quota?
> > > >> Do we
> > > >> > > say
> > > >> > > > > something like "there can be 10 active delegation tokens at
> a
> > > time
> > > >> > > that is
> > > >> > > > > created by superuserA for other users"?
> > > >> > > > > I think such a feature could be useful to limit the
> > > >> responsibility of
> > > >> > > said
> > > >> > > > > superuser (and blast radius in case of a faulty/malicious
> > > >> superuser)
> > > >> > > and
> > > >> > > > > also to limit potential programming errors. Do you have
> other
> > > use
> > > >> > cases
> > > >> > > > > too?
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Viktor
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <
> > > >> manikumar.reddy@gmail.com>
> > > >> > > > > wrote:
> > > >> > > > >
> > > >> > > > > > Hi Viktor,
> > > >> > > > > >
> > > >> > > > > > Thanks for taking over this KP.
> > > >> > > > > >
> > > >> > > > > > Current proposed ACL changes allows users to create tokens
> > for
> > > >> any
> > > >> > > user.
> > > >> > > > > > Thinking again about this, admins may want to configure a
> > user
> > > >> to
> > > >> > > > > > impersonate limited number of other users.
> > > >> > > > > > This allows us to configure fine-grained permissions. But
> > this
> > > >> > > requires
> > > >> > > > > a
> > > >> > > > > > new resourceType "User". What do you think?
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > Thanks,
> > > >> > > > > > Manikumar
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > > >> > > > > > viktorsomogyi@gmail.com>
> > > >> > > > > > wrote:
> > > >> > > > > >
> > > >> > > > > > > Hi Folks,
> > > >> > > > > > >
> > > >> > > > > > > I'm starting a vote on this.
> > > >> > > > > > >
> > > >> > > > > > > Viktor
> > > >> > > > > > >
> > > >> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > >> > > > > > > viktorsomogyi@gmail.com> wrote:
> > > >> > > > > > >
> > > >> > > > > > > > Hi Folks,
> > > >> > > > > > > >
> > > >> > > > > > > > I took over this issue from Manikumar. Recently
> another
> > > >> > > motivation
> > > >> > > > > have
> > > >> > > > > > > > been raised in Spark for this (SPARK-28173) and I
> think
> > > >> it'd be
> > > >> > > great
> > > >> > > > > > to
> > > >> > > > > > > > continue this task.
> > > >> > > > > > > > I updated the KIP and will wait for a few days to get
> > some
> > > >> > > feedback
> > > >> > > > > > then
> > > >> > > > > > > > proceed for the vote.
> > > >> > > > > > > >
> > > >> > > > > > > > Thanks,
> > > >> > > > > > > > Viktor
> > > >> > > > > > > >
> > > >> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> > > >> > > manikumar.reddy@gmail.com
> > > >> > > > > >
> > > >> > > > > > > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > >> Hi Harsha,
> > > >> > > > > > > >>
> > > >> > > > > > > >> Thanks for the review.
> > > >> > > > > > > >>
> > > >> > > > > > > >> With this KIP a designated superuser can create
> tokens
> > > >> without
> > > >> > > > > > requiring
> > > >> > > > > > > >> individual user credentials.
> > > >> > > > > > > >> Any client can authenticate brokers using the created
> > > >> tokens.
> > > >> > > We may
> > > >> > > > > > not
> > > >> > > > > > > >> call this as impersonation,
> > > >> > > > > > > >> since the clients API calls are executing on their
> own
> > > >> > > authenticated
> > > >> > > > > > > >> connections.
> > > >> > > > > > > >>
> > > >> > > > > > > >> Thanks,
> > > >> > > > > > > >> Manikumar
> > > >> > > > > > > >>
> > > >> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <
> > kafka@harsha.io>
> > > >> > wrote:
> > > >> > > > > > > >>
> > > >> > > > > > > >> > Hi Mani,
> > > >> > > > > > > >> > Overall KIP looks good to me. Can we call this
> > > >> > > > > > > >> Impersonation
> > > >> > > > > > > >> > support, which is what the KIP is doing?
> > > >> > > > > > > >> > Also instead of using super.uses as the config
> which
> > > >> > > essentially
> > > >> > > > > > > giving
> > > >> > > > > > > >> > cluster-wide support to the users, we can introduce
> > > >> > > > > > > impersonation.users
> > > >> > > > > > > >> as
> > > >> > > > > > > >> > a config and users listed in the config are allowed
> > to
> > > >> > > impersonate
> > > >> > > > > > > other
> > > >> > > > > > > >> > users.
> > > >> > > > > > > >> >
> > > >> > > > > > > >> > Thanks,
> > > >> > > > > > > >> > Harsha
> > > >> > > > > > > >> >
> > > >> > > > > > > >> >
> > > >> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > >> > > > > > > >> > > Bump up! to get some attention.
> > > >> > > > > > > >> > >
> > > >> > > > > > > >> > > BTW, recently Apache Spark added support for
> Kafka
> > > >> > > delegation
> > > >> > > > > > > token.
> > > >> > > > > > > >> > >
> https://issues.apache.org/jira/browse/SPARK-25501
> > > >> > > > > > > >> > >
> > > >> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > > >> > > > > > manikumar.reddy@gmail.com
> > > >> > > > > > > >
> > > >> > > > > > > >> > wrote:
> > > >> > > > > > > >> > >
> > > >> > > > > > > >> > > > Bump up! to get some attention.
> > > >> > > > > > > >> > > >
> > > >> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka
> > > delegation
> > > >> > > token
> > > >> > > > > > > support.
> > > >> > > > > > > >> > > >
> > https://issues.apache.org/jira/browse/SPARK-25501
> > > >> > > > > > > >> > > >
> > > >> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > >> > > > > > > >> manikumar.reddy@gmail.com>
> > > >> > > > > > > >> > > > wrote:
> > > >> > > > > > > >> > > >
> > > >> > > > > > > >> > > >> Hi all,
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >> I have created a KIP that proposes to allow
> > users
> > > to
> > > >> > > create
> > > >> > > > > > > >> delegation
> > > >> > > > > > > >> > > >> tokens for other users.
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> >
> > > >> > > > > > > >>
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >> Please take a look when you get a chance.
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >> Thanks,
> > > >> > > > > > > >> > > >> Manikumar
> > > >> > > > > > > >> > > >>
> > > >> > > > > > > >> > > >
> > > >> > > > > > > >> >
> > > >> > > > > > > >>
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Bumping this in the hope I can get more feedback and/or votes.

Thanks,
Viktor

On Tue, Sep 3, 2019 at 1:49 PM Gabor Somogyi <ga...@gmail.com>
wrote:

> +1 (non-binding) I've had a deeper look and this would be a good addition
> to Spark.
>
>
> On Thu, Aug 15, 2019 at 6:19 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com>
> wrote:
>
> > Started to implement my proposition and thought about it a little bit
> more
> > and it seems like I overthought the problem and we'd actually be better
> off
> > by having only the User resource type only and not CreateUsers. The
> problem
> > with CreateUsers is that a resource apparently is created only in addAcls
> > (at least in SimpleAclAuthorizer). Therefore we'd need to check before
> > creating the token that the owner user has been created and the token
> > creator has the permissions. Then add the user resource and the token.
> This
> > means that we'd only use CreateUsers when creating tokens iff the token
> > requester principal already has CreateTokens permissions with that user
> > (the owner) so it's kinda duplicate.
> > It would work though if we require the resources to be added beforehand
> but
> > it's not the case and is the detail of the Authorizer implementation.
> >
> > I'll update the KIP accordingly and apologies for the extra round :).
> >
> > Thanks,
> > Viktor
> >
> > On Wed, Aug 14, 2019 at 2:40 PM Viktor Somogyi-Vass <
> > viktorsomogyi@gmail.com>
> > wrote:
> >
> > > Sorry, reading my email the second time I probably wasn't clear.
> > > So basically the concept is that there is a user who can add other
> users
> > > as resources (such as userB and userC) prior to creating the "userA can
> > > create delegation token for userB and userC" association with
> > CreateTokens.
> > > To limit who can add new users as resources I thought we can introduce
> a
> > > CreateUser operation. It's true though that we could also say that a
> > Create
> > > operation permission on the Cluster resource would be enough to create
> > new
> > > users but I think from a generic security perspective it's better if we
> > > don't extend already existing operations.
> > > So a classic flow would be that prior to creating the delegation token
> > for
> > > userB, userB itself has to be added by another user who has CreateUser
> > > permissions. After this a CreateToken permission has to be created that
> > > says "userA can create delegation tokens for userB" and after this
> userA
> > > can actually create the token.
> > > Let me know what you think.
> > >
> > > Viktor
> > >
> > > On Wed, Aug 14, 2019 at 1:30 PM Manikumar <ma...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Why do we need  new ACL operation  "CreateUsers"?
> > >> I think,  "CreateTokens" Operation is sufficient to create "UserA can
> > >> create tokens for UserB, UserC" association.
> > >>
> > >> Thanks,
> > >>
> > >> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <
> > >> viktorsomogyi@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi Manikumar,
> > >> >
> > >> > Yea, I just brought up superuser for the sake of simplicity :).
> > >> > Anyway, your proposition makes sense to me, I'll modify the KIP for
> > >> this.
> > >> >
> > >> > The changes summarized:
> > >> > 1. We'll need a new ACL operation as well (say "CreateUsers") to
> > create
> > >> the
> > >> > "UserA can create tokens for UserB, UserC" association. This can be
> > used
> > >> > via the createAcls API of the AdminClient.
> > >> > 2. CreateToken will be a User level operation (instead of a Cluster
> > >> level
> > >> > as in previous drafts). So that means any user who wants to create a
> > >> > delegation token for other users will have to have an ACL set up by
> a
> > >> > higher level user to authorize this.
> > >> > 3. DescribeToken will also be a User level operation. In this case
> > >> tokenT
> > >> > owned by userB will be described if userA has a Describe ACL on
> tokenT
> > >> or
> > >> > has a DescribeToken ACL on userB. Note that in the latter case userA
> > >> will
> > >> > be able to describe all other tokens belonging to userB.
> > >> >
> > >> > Would this work for you?
> > >> >
> > >> > Viktor
> > >> >
> > >> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org>
> > >> wrote:
> > >> >
> > >> > > +1 for better access control here. In general, impersonating
> another
> > >> user
> > >> > > seems like it’s equivalent to super user access.
> > >> > >
> > >> > > Colin
> > >> > >
> > >> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> > >> > > > Hi Viktor,
> > >> > > >
> > >> > > > As per the KIP, It's not only superuser, any user with required
> > >> > > permissions
> > >> > > > (CreateTokens on Cluster Resource), can create the tokens for
> > other
> > >> > > users.
> > >> > > > Current proposed permissions defined like, "UserA can create
> > tokens
> > >> for
> > >> > > any
> > >> > > > user".
> > >> > > > I am thinking, can we change the permissions like "UserA can
> > create
> > >> > > tokens
> > >> > > > for UserB, UserC"?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> > >> > > viktorsomogyi@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hey Manikumar,
> > >> > > > >
> > >> > > > > Thanks for the feedback.
> > >> > > > > I'm not sure I fully grasp the use-case. Would this be a
> quota?
> > >> Do we
> > >> > > say
> > >> > > > > something like "there can be 10 active delegation tokens at a
> > time
> > >> > > that is
> > >> > > > > created by superuserA for other users"?
> > >> > > > > I think such a feature could be useful to limit the
> > >> responsibility of
> > >> > > said
> > >> > > > > superuser (and blast radius in case of a faulty/malicious
> > >> superuser)
> > >> > > and
> > >> > > > > also to limit potential programming errors. Do you have other
> > use
> > >> > cases
> > >> > > > > too?
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > Viktor
> > >> > > > >
> > >> > > > >
> > >> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <
> > >> manikumar.reddy@gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Hi Viktor,
> > >> > > > > >
> > >> > > > > > Thanks for taking over this KP.
> > >> > > > > >
> > >> > > > > > Current proposed ACL changes allows users to create tokens
> for
> > >> any
> > >> > > user.
> > >> > > > > > Thinking again about this, admins may want to configure a
> user
> > >> to
> > >> > > > > > impersonate limited number of other users.
> > >> > > > > > This allows us to configure fine-grained permissions. But
> this
> > >> > > requires
> > >> > > > > a
> > >> > > > > > new resourceType "User". What do you think?
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > Thanks,
> > >> > > > > > Manikumar
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > >> > > > > > viktorsomogyi@gmail.com>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Hi Folks,
> > >> > > > > > >
> > >> > > > > > > I'm starting a vote on this.
> > >> > > > > > >
> > >> > > > > > > Viktor
> > >> > > > > > >
> > >> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > >> > > > > > > viktorsomogyi@gmail.com> wrote:
> > >> > > > > > >
> > >> > > > > > > > Hi Folks,
> > >> > > > > > > >
> > >> > > > > > > > I took over this issue from Manikumar. Recently another
> > >> > > motivation
> > >> > > > > have
> > >> > > > > > > > been raised in Spark for this (SPARK-28173) and I think
> > >> it'd be
> > >> > > great
> > >> > > > > > to
> > >> > > > > > > > continue this task.
> > >> > > > > > > > I updated the KIP and will wait for a few days to get
> some
> > >> > > feedback
> > >> > > > > > then
> > >> > > > > > > > proceed for the vote.
> > >> > > > > > > >
> > >> > > > > > > > Thanks,
> > >> > > > > > > > Viktor
> > >> > > > > > > >
> > >> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> > >> > > manikumar.reddy@gmail.com
> > >> > > > > >
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > >> Hi Harsha,
> > >> > > > > > > >>
> > >> > > > > > > >> Thanks for the review.
> > >> > > > > > > >>
> > >> > > > > > > >> With this KIP a designated superuser can create tokens
> > >> without
> > >> > > > > > requiring
> > >> > > > > > > >> individual user credentials.
> > >> > > > > > > >> Any client can authenticate brokers using the created
> > >> tokens.
> > >> > > We may
> > >> > > > > > not
> > >> > > > > > > >> call this as impersonation,
> > >> > > > > > > >> since the clients API calls are executing on their own
> > >> > > authenticated
> > >> > > > > > > >> connections.
> > >> > > > > > > >>
> > >> > > > > > > >> Thanks,
> > >> > > > > > > >> Manikumar
> > >> > > > > > > >>
> > >> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <
> kafka@harsha.io>
> > >> > wrote:
> > >> > > > > > > >>
> > >> > > > > > > >> > Hi Mani,
> > >> > > > > > > >> > Overall KIP looks good to me. Can we call this
> > >> > > > > > > >> Impersonation
> > >> > > > > > > >> > support, which is what the KIP is doing?
> > >> > > > > > > >> > Also instead of using super.uses as the config which
> > >> > > essentially
> > >> > > > > > > giving
> > >> > > > > > > >> > cluster-wide support to the users, we can introduce
> > >> > > > > > > impersonation.users
> > >> > > > > > > >> as
> > >> > > > > > > >> > a config and users listed in the config are allowed
> to
> > >> > > impersonate
> > >> > > > > > > other
> > >> > > > > > > >> > users.
> > >> > > > > > > >> >
> > >> > > > > > > >> > Thanks,
> > >> > > > > > > >> > Harsha
> > >> > > > > > > >> >
> > >> > > > > > > >> >
> > >> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > >> > > > > > > >> > > Bump up! to get some attention.
> > >> > > > > > > >> > >
> > >> > > > > > > >> > > BTW, recently Apache Spark added support for Kafka
> > >> > > delegation
> > >> > > > > > > token.
> > >> > > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > >> > > > > > > >> > >
> > >> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > >> > > > > > manikumar.reddy@gmail.com
> > >> > > > > > > >
> > >> > > > > > > >> > wrote:
> > >> > > > > > > >> > >
> > >> > > > > > > >> > > > Bump up! to get some attention.
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka
> > delegation
> > >> > > token
> > >> > > > > > > support.
> > >> > > > > > > >> > > >
> https://issues.apache.org/jira/browse/SPARK-25501
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > >> > > > > > > >> manikumar.reddy@gmail.com>
> > >> > > > > > > >> > > > wrote:
> > >> > > > > > > >> > > >
> > >> > > > > > > >> > > >> Hi all,
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >> I have created a KIP that proposes to allow
> users
> > to
> > >> > > create
> > >> > > > > > > >> delegation
> > >> > > > > > > >> > > >> tokens for other users.
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> >
> > >> > > > > > > >>
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >> Please take a look when you get a chance.
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >> Thanks,
> > >> > > > > > > >> > > >> Manikumar
> > >> > > > > > > >> > > >>
> > >> > > > > > > >> > > >
> > >> > > > > > > >> >
> > >> > > > > > > >>
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Gabor Somogyi <ga...@gmail.com>.
+1 (non-binding) I've had a deeper look and this would be a good addition
to Spark.


On Thu, Aug 15, 2019 at 6:19 PM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Started to implement my proposition and thought about it a little bit more
> and it seems like I overthought the problem and we'd actually be better off
> by having only the User resource type only and not CreateUsers. The problem
> with CreateUsers is that a resource apparently is created only in addAcls
> (at least in SimpleAclAuthorizer). Therefore we'd need to check before
> creating the token that the owner user has been created and the token
> creator has the permissions. Then add the user resource and the token. This
> means that we'd only use CreateUsers when creating tokens iff the token
> requester principal already has CreateTokens permissions with that user
> (the owner) so it's kinda duplicate.
> It would work though if we require the resources to be added beforehand but
> it's not the case and is the detail of the Authorizer implementation.
>
> I'll update the KIP accordingly and apologies for the extra round :).
>
> Thanks,
> Viktor
>
> On Wed, Aug 14, 2019 at 2:40 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com>
> wrote:
>
> > Sorry, reading my email the second time I probably wasn't clear.
> > So basically the concept is that there is a user who can add other users
> > as resources (such as userB and userC) prior to creating the "userA can
> > create delegation token for userB and userC" association with
> CreateTokens.
> > To limit who can add new users as resources I thought we can introduce a
> > CreateUser operation. It's true though that we could also say that a
> Create
> > operation permission on the Cluster resource would be enough to create
> new
> > users but I think from a generic security perspective it's better if we
> > don't extend already existing operations.
> > So a classic flow would be that prior to creating the delegation token
> for
> > userB, userB itself has to be added by another user who has CreateUser
> > permissions. After this a CreateToken permission has to be created that
> > says "userA can create delegation tokens for userB" and after this userA
> > can actually create the token.
> > Let me know what you think.
> >
> > Viktor
> >
> > On Wed, Aug 14, 2019 at 1:30 PM Manikumar <ma...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Why do we need  new ACL operation  "CreateUsers"?
> >> I think,  "CreateTokens" Operation is sufficient to create "UserA can
> >> create tokens for UserB, UserC" association.
> >>
> >> Thanks,
> >>
> >> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <
> >> viktorsomogyi@gmail.com>
> >> wrote:
> >>
> >> > Hi Manikumar,
> >> >
> >> > Yea, I just brought up superuser for the sake of simplicity :).
> >> > Anyway, your proposition makes sense to me, I'll modify the KIP for
> >> this.
> >> >
> >> > The changes summarized:
> >> > 1. We'll need a new ACL operation as well (say "CreateUsers") to
> create
> >> the
> >> > "UserA can create tokens for UserB, UserC" association. This can be
> used
> >> > via the createAcls API of the AdminClient.
> >> > 2. CreateToken will be a User level operation (instead of a Cluster
> >> level
> >> > as in previous drafts). So that means any user who wants to create a
> >> > delegation token for other users will have to have an ACL set up by a
> >> > higher level user to authorize this.
> >> > 3. DescribeToken will also be a User level operation. In this case
> >> tokenT
> >> > owned by userB will be described if userA has a Describe ACL on tokenT
> >> or
> >> > has a DescribeToken ACL on userB. Note that in the latter case userA
> >> will
> >> > be able to describe all other tokens belonging to userB.
> >> >
> >> > Would this work for you?
> >> >
> >> > Viktor
> >> >
> >> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org>
> >> wrote:
> >> >
> >> > > +1 for better access control here. In general, impersonating another
> >> user
> >> > > seems like it’s equivalent to super user access.
> >> > >
> >> > > Colin
> >> > >
> >> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> >> > > > Hi Viktor,
> >> > > >
> >> > > > As per the KIP, It's not only superuser, any user with required
> >> > > permissions
> >> > > > (CreateTokens on Cluster Resource), can create the tokens for
> other
> >> > > users.
> >> > > > Current proposed permissions defined like, "UserA can create
> tokens
> >> for
> >> > > any
> >> > > > user".
> >> > > > I am thinking, can we change the permissions like "UserA can
> create
> >> > > tokens
> >> > > > for UserB, UserC"?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> >> > > viktorsomogyi@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Hey Manikumar,
> >> > > > >
> >> > > > > Thanks for the feedback.
> >> > > > > I'm not sure I fully grasp the use-case. Would this be a quota?
> >> Do we
> >> > > say
> >> > > > > something like "there can be 10 active delegation tokens at a
> time
> >> > > that is
> >> > > > > created by superuserA for other users"?
> >> > > > > I think such a feature could be useful to limit the
> >> responsibility of
> >> > > said
> >> > > > > superuser (and blast radius in case of a faulty/malicious
> >> superuser)
> >> > > and
> >> > > > > also to limit potential programming errors. Do you have other
> use
> >> > cases
> >> > > > > too?
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Viktor
> >> > > > >
> >> > > > >
> >> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <
> >> manikumar.reddy@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Hi Viktor,
> >> > > > > >
> >> > > > > > Thanks for taking over this KP.
> >> > > > > >
> >> > > > > > Current proposed ACL changes allows users to create tokens for
> >> any
> >> > > user.
> >> > > > > > Thinking again about this, admins may want to configure a user
> >> to
> >> > > > > > impersonate limited number of other users.
> >> > > > > > This allows us to configure fine-grained permissions. But this
> >> > > requires
> >> > > > > a
> >> > > > > > new resourceType "User". What do you think?
> >> > > > > >
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > > Manikumar
> >> > > > > >
> >> > > > > >
> >> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> >> > > > > > viktorsomogyi@gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Hi Folks,
> >> > > > > > >
> >> > > > > > > I'm starting a vote on this.
> >> > > > > > >
> >> > > > > > > Viktor
> >> > > > > > >
> >> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> >> > > > > > > viktorsomogyi@gmail.com> wrote:
> >> > > > > > >
> >> > > > > > > > Hi Folks,
> >> > > > > > > >
> >> > > > > > > > I took over this issue from Manikumar. Recently another
> >> > > motivation
> >> > > > > have
> >> > > > > > > > been raised in Spark for this (SPARK-28173) and I think
> >> it'd be
> >> > > great
> >> > > > > > to
> >> > > > > > > > continue this task.
> >> > > > > > > > I updated the KIP and will wait for a few days to get some
> >> > > feedback
> >> > > > > > then
> >> > > > > > > > proceed for the vote.
> >> > > > > > > >
> >> > > > > > > > Thanks,
> >> > > > > > > > Viktor
> >> > > > > > > >
> >> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> >> > > manikumar.reddy@gmail.com
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > >> Hi Harsha,
> >> > > > > > > >>
> >> > > > > > > >> Thanks for the review.
> >> > > > > > > >>
> >> > > > > > > >> With this KIP a designated superuser can create tokens
> >> without
> >> > > > > > requiring
> >> > > > > > > >> individual user credentials.
> >> > > > > > > >> Any client can authenticate brokers using the created
> >> tokens.
> >> > > We may
> >> > > > > > not
> >> > > > > > > >> call this as impersonation,
> >> > > > > > > >> since the clients API calls are executing on their own
> >> > > authenticated
> >> > > > > > > >> connections.
> >> > > > > > > >>
> >> > > > > > > >> Thanks,
> >> > > > > > > >> Manikumar
> >> > > > > > > >>
> >> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io>
> >> > wrote:
> >> > > > > > > >>
> >> > > > > > > >> > Hi Mani,
> >> > > > > > > >> > Overall KIP looks good to me. Can we call this
> >> > > > > > > >> Impersonation
> >> > > > > > > >> > support, which is what the KIP is doing?
> >> > > > > > > >> > Also instead of using super.uses as the config which
> >> > > essentially
> >> > > > > > > giving
> >> > > > > > > >> > cluster-wide support to the users, we can introduce
> >> > > > > > > impersonation.users
> >> > > > > > > >> as
> >> > > > > > > >> > a config and users listed in the config are allowed to
> >> > > impersonate
> >> > > > > > > other
> >> > > > > > > >> > users.
> >> > > > > > > >> >
> >> > > > > > > >> > Thanks,
> >> > > > > > > >> > Harsha
> >> > > > > > > >> >
> >> > > > > > > >> >
> >> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> >> > > > > > > >> > > Bump up! to get some attention.
> >> > > > > > > >> > >
> >> > > > > > > >> > > BTW, recently Apache Spark added support for Kafka
> >> > > delegation
> >> > > > > > > token.
> >> > > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> >> > > > > > > >> > >
> >> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> >> > > > > > manikumar.reddy@gmail.com
> >> > > > > > > >
> >> > > > > > > >> > wrote:
> >> > > > > > > >> > >
> >> > > > > > > >> > > > Bump up! to get some attention.
> >> > > > > > > >> > > >
> >> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka
> delegation
> >> > > token
> >> > > > > > > support.
> >> > > > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> >> > > > > > > >> > > >
> >> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> >> > > > > > > >> manikumar.reddy@gmail.com>
> >> > > > > > > >> > > > wrote:
> >> > > > > > > >> > > >
> >> > > > > > > >> > > >> Hi all,
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >> I have created a KIP that proposes to allow users
> to
> >> > > create
> >> > > > > > > >> delegation
> >> > > > > > > >> > > >> tokens for other users.
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >>
> >> > > > > > > >> >
> >> > > > > > > >>
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >> Please take a look when you get a chance.
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >> Thanks,
> >> > > > > > > >> > > >> Manikumar
> >> > > > > > > >> > > >>
> >> > > > > > > >> > > >
> >> > > > > > > >> >
> >> > > > > > > >>
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Started to implement my proposition and thought about it a little bit more
and it seems like I overthought the problem and we'd actually be better off
by having only the User resource type only and not CreateUsers. The problem
with CreateUsers is that a resource apparently is created only in addAcls
(at least in SimpleAclAuthorizer). Therefore we'd need to check before
creating the token that the owner user has been created and the token
creator has the permissions. Then add the user resource and the token. This
means that we'd only use CreateUsers when creating tokens iff the token
requester principal already has CreateTokens permissions with that user
(the owner) so it's kinda duplicate.
It would work though if we require the resources to be added beforehand but
it's not the case and is the detail of the Authorizer implementation.

I'll update the KIP accordingly and apologies for the extra round :).

Thanks,
Viktor

On Wed, Aug 14, 2019 at 2:40 PM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Sorry, reading my email the second time I probably wasn't clear.
> So basically the concept is that there is a user who can add other users
> as resources (such as userB and userC) prior to creating the "userA can
> create delegation token for userB and userC" association with CreateTokens.
> To limit who can add new users as resources I thought we can introduce a
> CreateUser operation. It's true though that we could also say that a Create
> operation permission on the Cluster resource would be enough to create new
> users but I think from a generic security perspective it's better if we
> don't extend already existing operations.
> So a classic flow would be that prior to creating the delegation token for
> userB, userB itself has to be added by another user who has CreateUser
> permissions. After this a CreateToken permission has to be created that
> says "userA can create delegation tokens for userB" and after this userA
> can actually create the token.
> Let me know what you think.
>
> Viktor
>
> On Wed, Aug 14, 2019 at 1:30 PM Manikumar <ma...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Why do we need  new ACL operation  "CreateUsers"?
>> I think,  "CreateTokens" Operation is sufficient to create "UserA can
>> create tokens for UserB, UserC" association.
>>
>> Thanks,
>>
>> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <
>> viktorsomogyi@gmail.com>
>> wrote:
>>
>> > Hi Manikumar,
>> >
>> > Yea, I just brought up superuser for the sake of simplicity :).
>> > Anyway, your proposition makes sense to me, I'll modify the KIP for
>> this.
>> >
>> > The changes summarized:
>> > 1. We'll need a new ACL operation as well (say "CreateUsers") to create
>> the
>> > "UserA can create tokens for UserB, UserC" association. This can be used
>> > via the createAcls API of the AdminClient.
>> > 2. CreateToken will be a User level operation (instead of a Cluster
>> level
>> > as in previous drafts). So that means any user who wants to create a
>> > delegation token for other users will have to have an ACL set up by a
>> > higher level user to authorize this.
>> > 3. DescribeToken will also be a User level operation. In this case
>> tokenT
>> > owned by userB will be described if userA has a Describe ACL on tokenT
>> or
>> > has a DescribeToken ACL on userB. Note that in the latter case userA
>> will
>> > be able to describe all other tokens belonging to userB.
>> >
>> > Would this work for you?
>> >
>> > Viktor
>> >
>> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org>
>> wrote:
>> >
>> > > +1 for better access control here. In general, impersonating another
>> user
>> > > seems like it’s equivalent to super user access.
>> > >
>> > > Colin
>> > >
>> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
>> > > > Hi Viktor,
>> > > >
>> > > > As per the KIP, It's not only superuser, any user with required
>> > > permissions
>> > > > (CreateTokens on Cluster Resource), can create the tokens for other
>> > > users.
>> > > > Current proposed permissions defined like, "UserA can create tokens
>> for
>> > > any
>> > > > user".
>> > > > I am thinking, can we change the permissions like "UserA can create
>> > > tokens
>> > > > for UserB, UserC"?
>> > > >
>> > > > Thanks,
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
>> > > viktorsomogyi@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hey Manikumar,
>> > > > >
>> > > > > Thanks for the feedback.
>> > > > > I'm not sure I fully grasp the use-case. Would this be a quota?
>> Do we
>> > > say
>> > > > > something like "there can be 10 active delegation tokens at a time
>> > > that is
>> > > > > created by superuserA for other users"?
>> > > > > I think such a feature could be useful to limit the
>> responsibility of
>> > > said
>> > > > > superuser (and blast radius in case of a faulty/malicious
>> superuser)
>> > > and
>> > > > > also to limit potential programming errors. Do you have other use
>> > cases
>> > > > > too?
>> > > > >
>> > > > > Thanks,
>> > > > > Viktor
>> > > > >
>> > > > >
>> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <
>> manikumar.reddy@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi Viktor,
>> > > > > >
>> > > > > > Thanks for taking over this KP.
>> > > > > >
>> > > > > > Current proposed ACL changes allows users to create tokens for
>> any
>> > > user.
>> > > > > > Thinking again about this, admins may want to configure a user
>> to
>> > > > > > impersonate limited number of other users.
>> > > > > > This allows us to configure fine-grained permissions. But this
>> > > requires
>> > > > > a
>> > > > > > new resourceType "User". What do you think?
>> > > > > >
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Manikumar
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
>> > > > > > viktorsomogyi@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Hi Folks,
>> > > > > > >
>> > > > > > > I'm starting a vote on this.
>> > > > > > >
>> > > > > > > Viktor
>> > > > > > >
>> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
>> > > > > > > viktorsomogyi@gmail.com> wrote:
>> > > > > > >
>> > > > > > > > Hi Folks,
>> > > > > > > >
>> > > > > > > > I took over this issue from Manikumar. Recently another
>> > > motivation
>> > > > > have
>> > > > > > > > been raised in Spark for this (SPARK-28173) and I think
>> it'd be
>> > > great
>> > > > > > to
>> > > > > > > > continue this task.
>> > > > > > > > I updated the KIP and will wait for a few days to get some
>> > > feedback
>> > > > > > then
>> > > > > > > > proceed for the vote.
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > Viktor
>> > > > > > > >
>> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
>> > > manikumar.reddy@gmail.com
>> > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > >> Hi Harsha,
>> > > > > > > >>
>> > > > > > > >> Thanks for the review.
>> > > > > > > >>
>> > > > > > > >> With this KIP a designated superuser can create tokens
>> without
>> > > > > > requiring
>> > > > > > > >> individual user credentials.
>> > > > > > > >> Any client can authenticate brokers using the created
>> tokens.
>> > > We may
>> > > > > > not
>> > > > > > > >> call this as impersonation,
>> > > > > > > >> since the clients API calls are executing on their own
>> > > authenticated
>> > > > > > > >> connections.
>> > > > > > > >>
>> > > > > > > >> Thanks,
>> > > > > > > >> Manikumar
>> > > > > > > >>
>> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io>
>> > wrote:
>> > > > > > > >>
>> > > > > > > >> > Hi Mani,
>> > > > > > > >> > Overall KIP looks good to me. Can we call this
>> > > > > > > >> Impersonation
>> > > > > > > >> > support, which is what the KIP is doing?
>> > > > > > > >> > Also instead of using super.uses as the config which
>> > > essentially
>> > > > > > > giving
>> > > > > > > >> > cluster-wide support to the users, we can introduce
>> > > > > > > impersonation.users
>> > > > > > > >> as
>> > > > > > > >> > a config and users listed in the config are allowed to
>> > > impersonate
>> > > > > > > other
>> > > > > > > >> > users.
>> > > > > > > >> >
>> > > > > > > >> > Thanks,
>> > > > > > > >> > Harsha
>> > > > > > > >> >
>> > > > > > > >> >
>> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
>> > > > > > > >> > > Bump up! to get some attention.
>> > > > > > > >> > >
>> > > > > > > >> > > BTW, recently Apache Spark added support for Kafka
>> > > delegation
>> > > > > > > token.
>> > > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
>> > > > > > > >> > >
>> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
>> > > > > > manikumar.reddy@gmail.com
>> > > > > > > >
>> > > > > > > >> > wrote:
>> > > > > > > >> > >
>> > > > > > > >> > > > Bump up! to get some attention.
>> > > > > > > >> > > >
>> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka delegation
>> > > token
>> > > > > > > support.
>> > > > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
>> > > > > > > >> > > >
>> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
>> > > > > > > >> manikumar.reddy@gmail.com>
>> > > > > > > >> > > > wrote:
>> > > > > > > >> > > >
>> > > > > > > >> > > >> Hi all,
>> > > > > > > >> > > >>
>> > > > > > > >> > > >> I have created a KIP that proposes to allow users to
>> > > create
>> > > > > > > >> delegation
>> > > > > > > >> > > >> tokens for other users.
>> > > > > > > >> > > >>
>> > > > > > > >> > > >>
>> > > > > > > >> > > >>
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > >
>> > > > > >
>> > > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
>> > > > > > > >> > > >>
>> > > > > > > >> > > >> Please take a look when you get a chance.
>> > > > > > > >> > > >>
>> > > > > > > >> > > >> Thanks,
>> > > > > > > >> > > >> Manikumar
>> > > > > > > >> > > >>
>> > > > > > > >> > > >
>> > > > > > > >> >
>> > > > > > > >>
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Sorry, reading my email the second time I probably wasn't clear.
So basically the concept is that there is a user who can add other users as
resources (such as userB and userC) prior to creating the "userA can create
delegation token for userB and userC" association with CreateTokens. To
limit who can add new users as resources I thought we can introduce a
CreateUser operation. It's true though that we could also say that a Create
operation permission on the Cluster resource would be enough to create new
users but I think from a generic security perspective it's better if we
don't extend already existing operations.
So a classic flow would be that prior to creating the delegation token for
userB, userB itself has to be added by another user who has CreateUser
permissions. After this a CreateToken permission has to be created that
says "userA can create delegation tokens for userB" and after this userA
can actually create the token.
Let me know what you think.

Viktor

On Wed, Aug 14, 2019 at 1:30 PM Manikumar <ma...@gmail.com> wrote:

> Hi,
>
> Why do we need  new ACL operation  "CreateUsers"?
> I think,  "CreateTokens" Operation is sufficient to create "UserA can
> create tokens for UserB, UserC" association.
>
> Thanks,
>
> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com>
> wrote:
>
> > Hi Manikumar,
> >
> > Yea, I just brought up superuser for the sake of simplicity :).
> > Anyway, your proposition makes sense to me, I'll modify the KIP for this.
> >
> > The changes summarized:
> > 1. We'll need a new ACL operation as well (say "CreateUsers") to create
> the
> > "UserA can create tokens for UserB, UserC" association. This can be used
> > via the createAcls API of the AdminClient.
> > 2. CreateToken will be a User level operation (instead of a Cluster level
> > as in previous drafts). So that means any user who wants to create a
> > delegation token for other users will have to have an ACL set up by a
> > higher level user to authorize this.
> > 3. DescribeToken will also be a User level operation. In this case tokenT
> > owned by userB will be described if userA has a Describe ACL on tokenT or
> > has a DescribeToken ACL on userB. Note that in the latter case userA will
> > be able to describe all other tokens belonging to userB.
> >
> > Would this work for you?
> >
> > Viktor
> >
> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org> wrote:
> >
> > > +1 for better access control here. In general, impersonating another
> user
> > > seems like it’s equivalent to super user access.
> > >
> > > Colin
> > >
> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> > > > Hi Viktor,
> > > >
> > > > As per the KIP, It's not only superuser, any user with required
> > > permissions
> > > > (CreateTokens on Cluster Resource), can create the tokens for other
> > > users.
> > > > Current proposed permissions defined like, "UserA can create tokens
> for
> > > any
> > > > user".
> > > > I am thinking, can we change the permissions like "UserA can create
> > > tokens
> > > > for UserB, UserC"?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> > > viktorsomogyi@gmail.com>
> > > > wrote:
> > > >
> > > > > Hey Manikumar,
> > > > >
> > > > > Thanks for the feedback.
> > > > > I'm not sure I fully grasp the use-case. Would this be a quota? Do
> we
> > > say
> > > > > something like "there can be 10 active delegation tokens at a time
> > > that is
> > > > > created by superuserA for other users"?
> > > > > I think such a feature could be useful to limit the responsibility
> of
> > > said
> > > > > superuser (and blast radius in case of a faulty/malicious
> superuser)
> > > and
> > > > > also to limit potential programming errors. Do you have other use
> > cases
> > > > > too?
> > > > >
> > > > > Thanks,
> > > > > Viktor
> > > > >
> > > > >
> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <
> manikumar.reddy@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Viktor,
> > > > > >
> > > > > > Thanks for taking over this KP.
> > > > > >
> > > > > > Current proposed ACL changes allows users to create tokens for
> any
> > > user.
> > > > > > Thinking again about this, admins may want to configure a user to
> > > > > > impersonate limited number of other users.
> > > > > > This allows us to configure fine-grained permissions. But this
> > > requires
> > > > > a
> > > > > > new resourceType "User". What do you think?
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Manikumar
> > > > > >
> > > > > >
> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > > > > > viktorsomogyi@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Folks,
> > > > > > >
> > > > > > > I'm starting a vote on this.
> > > > > > >
> > > > > > > Viktor
> > > > > > >
> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > > > > > viktorsomogyi@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi Folks,
> > > > > > > >
> > > > > > > > I took over this issue from Manikumar. Recently another
> > > motivation
> > > > > have
> > > > > > > > been raised in Spark for this (SPARK-28173) and I think it'd
> be
> > > great
> > > > > > to
> > > > > > > > continue this task.
> > > > > > > > I updated the KIP and will wait for a few days to get some
> > > feedback
> > > > > > then
> > > > > > > > proceed for the vote.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Viktor
> > > > > > > >
> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> > > manikumar.reddy@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> Hi Harsha,
> > > > > > > >>
> > > > > > > >> Thanks for the review.
> > > > > > > >>
> > > > > > > >> With this KIP a designated superuser can create tokens
> without
> > > > > > requiring
> > > > > > > >> individual user credentials.
> > > > > > > >> Any client can authenticate brokers using the created
> tokens.
> > > We may
> > > > > > not
> > > > > > > >> call this as impersonation,
> > > > > > > >> since the clients API calls are executing on their own
> > > authenticated
> > > > > > > >> connections.
> > > > > > > >>
> > > > > > > >> Thanks,
> > > > > > > >> Manikumar
> > > > > > > >>
> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io>
> > wrote:
> > > > > > > >>
> > > > > > > >> > Hi Mani,
> > > > > > > >> > Overall KIP looks good to me. Can we call this
> > > > > > > >> Impersonation
> > > > > > > >> > support, which is what the KIP is doing?
> > > > > > > >> > Also instead of using super.uses as the config which
> > > essentially
> > > > > > > giving
> > > > > > > >> > cluster-wide support to the users, we can introduce
> > > > > > > impersonation.users
> > > > > > > >> as
> > > > > > > >> > a config and users listed in the config are allowed to
> > > impersonate
> > > > > > > other
> > > > > > > >> > users.
> > > > > > > >> >
> > > > > > > >> > Thanks,
> > > > > > > >> > Harsha
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > > > > > >> > > Bump up! to get some attention.
> > > > > > > >> > >
> > > > > > > >> > > BTW, recently Apache Spark added support for Kafka
> > > delegation
> > > > > > > token.
> > > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > > > >> > >
> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > > > > > manikumar.reddy@gmail.com
> > > > > > > >
> > > > > > > >> > wrote:
> > > > > > > >> > >
> > > > > > > >> > > > Bump up! to get some attention.
> > > > > > > >> > > >
> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka delegation
> > > token
> > > > > > > support.
> > > > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > > > >> > > >
> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > > > > > >> manikumar.reddy@gmail.com>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > >> Hi all,
> > > > > > > >> > > >>
> > > > > > > >> > > >> I have created a KIP that proposes to allow users to
> > > create
> > > > > > > >> delegation
> > > > > > > >> > > >> tokens for other users.
> > > > > > > >> > > >>
> > > > > > > >> > > >>
> > > > > > > >> > > >>
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > > > > > >> > > >>
> > > > > > > >> > > >> Please take a look when you get a chance.
> > > > > > > >> > > >>
> > > > > > > >> > > >> Thanks,
> > > > > > > >> > > >> Manikumar
> > > > > > > >> > > >>
> > > > > > > >> > > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Hi,

Why do we need  new ACL operation  "CreateUsers"?
I think,  "CreateTokens" Operation is sufficient to create "UserA can
create tokens for UserB, UserC" association.

Thanks,

On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Hi Manikumar,
>
> Yea, I just brought up superuser for the sake of simplicity :).
> Anyway, your proposition makes sense to me, I'll modify the KIP for this.
>
> The changes summarized:
> 1. We'll need a new ACL operation as well (say "CreateUsers") to create the
> "UserA can create tokens for UserB, UserC" association. This can be used
> via the createAcls API of the AdminClient.
> 2. CreateToken will be a User level operation (instead of a Cluster level
> as in previous drafts). So that means any user who wants to create a
> delegation token for other users will have to have an ACL set up by a
> higher level user to authorize this.
> 3. DescribeToken will also be a User level operation. In this case tokenT
> owned by userB will be described if userA has a Describe ACL on tokenT or
> has a DescribeToken ACL on userB. Note that in the latter case userA will
> be able to describe all other tokens belonging to userB.
>
> Would this work for you?
>
> Viktor
>
> On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org> wrote:
>
> > +1 for better access control here. In general, impersonating another user
> > seems like it’s equivalent to super user access.
> >
> > Colin
> >
> > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> > > Hi Viktor,
> > >
> > > As per the KIP, It's not only superuser, any user with required
> > permissions
> > > (CreateTokens on Cluster Resource), can create the tokens for other
> > users.
> > > Current proposed permissions defined like, "UserA can create tokens for
> > any
> > > user".
> > > I am thinking, can we change the permissions like "UserA can create
> > tokens
> > > for UserB, UserC"?
> > >
> > > Thanks,
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> > viktorsomogyi@gmail.com>
> > > wrote:
> > >
> > > > Hey Manikumar,
> > > >
> > > > Thanks for the feedback.
> > > > I'm not sure I fully grasp the use-case. Would this be a quota? Do we
> > say
> > > > something like "there can be 10 active delegation tokens at a time
> > that is
> > > > created by superuserA for other users"?
> > > > I think such a feature could be useful to limit the responsibility of
> > said
> > > > superuser (and blast radius in case of a faulty/malicious superuser)
> > and
> > > > also to limit potential programming errors. Do you have other use
> cases
> > > > too?
> > > >
> > > > Thanks,
> > > > Viktor
> > > >
> > > >
> > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <ma...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Viktor,
> > > > >
> > > > > Thanks for taking over this KP.
> > > > >
> > > > > Current proposed ACL changes allows users to create tokens for any
> > user.
> > > > > Thinking again about this, admins may want to configure a user to
> > > > > impersonate limited number of other users.
> > > > > This allows us to configure fine-grained permissions. But this
> > requires
> > > > a
> > > > > new resourceType "User". What do you think?
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Manikumar
> > > > >
> > > > >
> > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > > > > viktorsomogyi@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Folks,
> > > > > >
> > > > > > I'm starting a vote on this.
> > > > > >
> > > > > > Viktor
> > > > > >
> > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > > > > viktorsomogyi@gmail.com> wrote:
> > > > > >
> > > > > > > Hi Folks,
> > > > > > >
> > > > > > > I took over this issue from Manikumar. Recently another
> > motivation
> > > > have
> > > > > > > been raised in Spark for this (SPARK-28173) and I think it'd be
> > great
> > > > > to
> > > > > > > continue this task.
> > > > > > > I updated the KIP and will wait for a few days to get some
> > feedback
> > > > > then
> > > > > > > proceed for the vote.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Viktor
> > > > > > >
> > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> > manikumar.reddy@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Harsha,
> > > > > > >>
> > > > > > >> Thanks for the review.
> > > > > > >>
> > > > > > >> With this KIP a designated superuser can create tokens without
> > > > > requiring
> > > > > > >> individual user credentials.
> > > > > > >> Any client can authenticate brokers using the created tokens.
> > We may
> > > > > not
> > > > > > >> call this as impersonation,
> > > > > > >> since the clients API calls are executing on their own
> > authenticated
> > > > > > >> connections.
> > > > > > >>
> > > > > > >> Thanks,
> > > > > > >> Manikumar
> > > > > > >>
> > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io>
> wrote:
> > > > > > >>
> > > > > > >> > Hi Mani,
> > > > > > >> > Overall KIP looks good to me. Can we call this
> > > > > > >> Impersonation
> > > > > > >> > support, which is what the KIP is doing?
> > > > > > >> > Also instead of using super.uses as the config which
> > essentially
> > > > > > giving
> > > > > > >> > cluster-wide support to the users, we can introduce
> > > > > > impersonation.users
> > > > > > >> as
> > > > > > >> > a config and users listed in the config are allowed to
> > impersonate
> > > > > > other
> > > > > > >> > users.
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Harsha
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > > > > >> > > Bump up! to get some attention.
> > > > > > >> > >
> > > > > > >> > > BTW, recently Apache Spark added support for Kafka
> > delegation
> > > > > > token.
> > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > > >> > >
> > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > > > > manikumar.reddy@gmail.com
> > > > > > >
> > > > > > >> > wrote:
> > > > > > >> > >
> > > > > > >> > > > Bump up! to get some attention.
> > > > > > >> > > >
> > > > > > >> > > > BTW, recently Apache Spark added for Kafka delegation
> > token
> > > > > > support.
> > > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > > >> > > >
> > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > > > > >> manikumar.reddy@gmail.com>
> > > > > > >> > > > wrote:
> > > > > > >> > > >
> > > > > > >> > > >> Hi all,
> > > > > > >> > > >>
> > > > > > >> > > >> I have created a KIP that proposes to allow users to
> > create
> > > > > > >> delegation
> > > > > > >> > > >> tokens for other users.
> > > > > > >> > > >>
> > > > > > >> > > >>
> > > > > > >> > > >>
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > > > > >> > > >>
> > > > > > >> > > >> Please take a look when you get a chance.
> > > > > > >> > > >>
> > > > > > >> > > >> Thanks,
> > > > > > >> > > >> Manikumar
> > > > > > >> > > >>
> > > > > > >> > > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Hi Manikumar,

Yea, I just brought up superuser for the sake of simplicity :).
Anyway, your proposition makes sense to me, I'll modify the KIP for this.

The changes summarized:
1. We'll need a new ACL operation as well (say "CreateUsers") to create the
"UserA can create tokens for UserB, UserC" association. This can be used
via the createAcls API of the AdminClient.
2. CreateToken will be a User level operation (instead of a Cluster level
as in previous drafts). So that means any user who wants to create a
delegation token for other users will have to have an ACL set up by a
higher level user to authorize this.
3. DescribeToken will also be a User level operation. In this case tokenT
owned by userB will be described if userA has a Describe ACL on tokenT or
has a DescribeToken ACL on userB. Note that in the latter case userA will
be able to describe all other tokens belonging to userB.

Would this work for you?

Viktor

On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe <cm...@apache.org> wrote:

> +1 for better access control here. In general, impersonating another user
> seems like it’s equivalent to super user access.
>
> Colin
>
> On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> > Hi Viktor,
> >
> > As per the KIP, It's not only superuser, any user with required
> permissions
> > (CreateTokens on Cluster Resource), can create the tokens for other
> users.
> > Current proposed permissions defined like, "UserA can create tokens for
> any
> > user".
> > I am thinking, can we change the permissions like "UserA can create
> tokens
> > for UserB, UserC"?
> >
> > Thanks,
> >
> >
> >
> >
> >
> >
> > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com>
> > wrote:
> >
> > > Hey Manikumar,
> > >
> > > Thanks for the feedback.
> > > I'm not sure I fully grasp the use-case. Would this be a quota? Do we
> say
> > > something like "there can be 10 active delegation tokens at a time
> that is
> > > created by superuserA for other users"?
> > > I think such a feature could be useful to limit the responsibility of
> said
> > > superuser (and blast radius in case of a faulty/malicious superuser)
> and
> > > also to limit potential programming errors. Do you have other use cases
> > > too?
> > >
> > > Thanks,
> > > Viktor
> > >
> > >
> > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <ma...@gmail.com>
> > > wrote:
> > >
> > > > Hi Viktor,
> > > >
> > > > Thanks for taking over this KP.
> > > >
> > > > Current proposed ACL changes allows users to create tokens for any
> user.
> > > > Thinking again about this, admins may want to configure a user to
> > > > impersonate limited number of other users.
> > > > This allows us to configure fine-grained permissions. But this
> requires
> > > a
> > > > new resourceType "User". What do you think?
> > > >
> > > >
> > > > Thanks,
> > > > Manikumar
> > > >
> > > >
> > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > > > viktorsomogyi@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Folks,
> > > > >
> > > > > I'm starting a vote on this.
> > > > >
> > > > > Viktor
> > > > >
> > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > > > viktorsomogyi@gmail.com> wrote:
> > > > >
> > > > > > Hi Folks,
> > > > > >
> > > > > > I took over this issue from Manikumar. Recently another
> motivation
> > > have
> > > > > > been raised in Spark for this (SPARK-28173) and I think it'd be
> great
> > > > to
> > > > > > continue this task.
> > > > > > I updated the KIP and will wait for a few days to get some
> feedback
> > > > then
> > > > > > proceed for the vote.
> > > > > >
> > > > > > Thanks,
> > > > > > Viktor
> > > > > >
> > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <
> manikumar.reddy@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> Hi Harsha,
> > > > > >>
> > > > > >> Thanks for the review.
> > > > > >>
> > > > > >> With this KIP a designated superuser can create tokens without
> > > > requiring
> > > > > >> individual user credentials.
> > > > > >> Any client can authenticate brokers using the created tokens.
> We may
> > > > not
> > > > > >> call this as impersonation,
> > > > > >> since the clients API calls are executing on their own
> authenticated
> > > > > >> connections.
> > > > > >>
> > > > > >> Thanks,
> > > > > >> Manikumar
> > > > > >>
> > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
> > > > > >>
> > > > > >> > Hi Mani,
> > > > > >> > Overall KIP looks good to me. Can we call this
> > > > > >> Impersonation
> > > > > >> > support, which is what the KIP is doing?
> > > > > >> > Also instead of using super.uses as the config which
> essentially
> > > > > giving
> > > > > >> > cluster-wide support to the users, we can introduce
> > > > > impersonation.users
> > > > > >> as
> > > > > >> > a config and users listed in the config are allowed to
> impersonate
> > > > > other
> > > > > >> > users.
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Harsha
> > > > > >> >
> > > > > >> >
> > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > > > >> > > Bump up! to get some attention.
> > > > > >> > >
> > > > > >> > > BTW, recently Apache Spark added support for Kafka
> delegation
> > > > > token.
> > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > >> > >
> > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > > > manikumar.reddy@gmail.com
> > > > > >
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > > > Bump up! to get some attention.
> > > > > >> > > >
> > > > > >> > > > BTW, recently Apache Spark added for Kafka delegation
> token
> > > > > support.
> > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > > >> > > >
> > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > > > >> manikumar.reddy@gmail.com>
> > > > > >> > > > wrote:
> > > > > >> > > >
> > > > > >> > > >> Hi all,
> > > > > >> > > >>
> > > > > >> > > >> I have created a KIP that proposes to allow users to
> create
> > > > > >> delegation
> > > > > >> > > >> tokens for other users.
> > > > > >> > > >>
> > > > > >> > > >>
> > > > > >> > > >>
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > > > >> > > >>
> > > > > >> > > >> Please take a look when you get a chance.
> > > > > >> > > >>
> > > > > >> > > >> Thanks,
> > > > > >> > > >> Manikumar
> > > > > >> > > >>
> > > > > >> > > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Colin McCabe <cm...@apache.org>.
+1 for better access control here. In general, impersonating another user seems like it’s equivalent to super user access.

Colin

On Mon, Aug 12, 2019, at 05:43, Manikumar wrote:
> Hi Viktor,
> 
> As per the KIP, It's not only superuser, any user with required permissions
> (CreateTokens on Cluster Resource), can create the tokens for other users.
> Current proposed permissions defined like, "UserA can create tokens for any
> user".
> I am thinking, can we change the permissions like "UserA can create tokens
> for UserB, UserC"?
> 
> Thanks,
> 
> 
> 
> 
> 
> 
> On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <vi...@gmail.com>
> wrote:
> 
> > Hey Manikumar,
> >
> > Thanks for the feedback.
> > I'm not sure I fully grasp the use-case. Would this be a quota? Do we say
> > something like "there can be 10 active delegation tokens at a time that is
> > created by superuserA for other users"?
> > I think such a feature could be useful to limit the responsibility of said
> > superuser (and blast radius in case of a faulty/malicious superuser) and
> > also to limit potential programming errors. Do you have other use cases
> > too?
> >
> > Thanks,
> > Viktor
> >
> >
> > On Tue, Aug 6, 2019 at 1:28 PM Manikumar <ma...@gmail.com>
> > wrote:
> >
> > > Hi Viktor,
> > >
> > > Thanks for taking over this KP.
> > >
> > > Current proposed ACL changes allows users to create tokens for any user.
> > > Thinking again about this, admins may want to configure a user to
> > > impersonate limited number of other users.
> > > This allows us to configure fine-grained permissions. But this requires
> > a
> > > new resourceType "User". What do you think?
> > >
> > >
> > > Thanks,
> > > Manikumar
> > >
> > >
> > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > > viktorsomogyi@gmail.com>
> > > wrote:
> > >
> > > > Hi Folks,
> > > >
> > > > I'm starting a vote on this.
> > > >
> > > > Viktor
> > > >
> > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > > viktorsomogyi@gmail.com> wrote:
> > > >
> > > > > Hi Folks,
> > > > >
> > > > > I took over this issue from Manikumar. Recently another motivation
> > have
> > > > > been raised in Spark for this (SPARK-28173) and I think it'd be great
> > > to
> > > > > continue this task.
> > > > > I updated the KIP and will wait for a few days to get some feedback
> > > then
> > > > > proceed for the vote.
> > > > >
> > > > > Thanks,
> > > > > Viktor
> > > > >
> > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <manikumar.reddy@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > >> Hi Harsha,
> > > > >>
> > > > >> Thanks for the review.
> > > > >>
> > > > >> With this KIP a designated superuser can create tokens without
> > > requiring
> > > > >> individual user credentials.
> > > > >> Any client can authenticate brokers using the created tokens. We may
> > > not
> > > > >> call this as impersonation,
> > > > >> since the clients API calls are executing on their own authenticated
> > > > >> connections.
> > > > >>
> > > > >> Thanks,
> > > > >> Manikumar
> > > > >>
> > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
> > > > >>
> > > > >> > Hi Mani,
> > > > >> > Overall KIP looks good to me. Can we call this
> > > > >> Impersonation
> > > > >> > support, which is what the KIP is doing?
> > > > >> > Also instead of using super.uses as the config which essentially
> > > > giving
> > > > >> > cluster-wide support to the users, we can introduce
> > > > impersonation.users
> > > > >> as
> > > > >> > a config and users listed in the config are allowed to impersonate
> > > > other
> > > > >> > users.
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Harsha
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > > >> > > Bump up! to get some attention.
> > > > >> > >
> > > > >> > > BTW, recently Apache Spark added support for Kafka delegation
> > > > token.
> > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > >> > >
> > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > > manikumar.reddy@gmail.com
> > > > >
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > > Bump up! to get some attention.
> > > > >> > > >
> > > > >> > > > BTW, recently Apache Spark added for Kafka delegation token
> > > > support.
> > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > > >> > > >
> > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > > >> manikumar.reddy@gmail.com>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > >> Hi all,
> > > > >> > > >>
> > > > >> > > >> I have created a KIP that proposes to allow users to create
> > > > >> delegation
> > > > >> > > >> tokens for other users.
> > > > >> > > >>
> > > > >> > > >>
> > > > >> > > >>
> > > > >> >
> > > > >>
> > > >
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > > >> > > >>
> > > > >> > > >> Please take a look when you get a chance.
> > > > >> > > >>
> > > > >> > > >> Thanks,
> > > > >> > > >> Manikumar
> > > > >> > > >>
> > > > >> > > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Hi Viktor,

As per the KIP, It's not only superuser, any user with required permissions
(CreateTokens on Cluster Resource), can create the tokens for other users.
Current proposed permissions defined like, "UserA can create tokens for any
user".
I am thinking, can we change the permissions like  "UserA can create tokens
for UserB, UserC"?

Thanks,






On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Hey Manikumar,
>
> Thanks for the feedback.
> I'm not sure I fully grasp the use-case. Would this be a quota? Do we say
> something like "there can be 10 active delegation tokens at a time that is
> created by superuserA for other users"?
> I think such a feature could be useful to limit the responsibility of said
> superuser (and blast radius in case of a faulty/malicious superuser) and
> also to limit potential programming errors. Do you have other use cases
> too?
>
> Thanks,
> Viktor
>
>
> On Tue, Aug 6, 2019 at 1:28 PM Manikumar <ma...@gmail.com>
> wrote:
>
> > Hi Viktor,
> >
> > Thanks for taking over this KP.
> >
> > Current proposed ACL changes allows users to create tokens for any user.
> > Thinking again about this, admins may want to configure a user to
> > impersonate limited number of other users.
> > This allows us to configure fine-grained permissions.  But this requires
> a
> > new resourceType "User".  What do you think?
> >
> >
> > Thanks,
> > Manikumar
> >
> >
> > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> > viktorsomogyi@gmail.com>
> > wrote:
> >
> > > Hi Folks,
> > >
> > > I'm starting a vote on this.
> > >
> > > Viktor
> > >
> > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > > viktorsomogyi@gmail.com> wrote:
> > >
> > > > Hi Folks,
> > > >
> > > > I took over this issue from Manikumar. Recently another motivation
> have
> > > > been raised in Spark for this (SPARK-28173) and I think it'd be great
> > to
> > > > continue this task.
> > > > I updated the KIP and will wait for a few days to get some feedback
> > then
> > > > proceed for the vote.
> > > >
> > > > Thanks,
> > > > Viktor
> > > >
> > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <manikumar.reddy@gmail.com
> >
> > > > wrote:
> > > >
> > > >> Hi Harsha,
> > > >>
> > > >> Thanks for the review.
> > > >>
> > > >> With this KIP a designated superuser can create tokens without
> > requiring
> > > >> individual user credentials.
> > > >> Any client can authenticate brokers using the created tokens. We may
> > not
> > > >> call this as impersonation,
> > > >> since the clients API calls are executing on their own authenticated
> > > >> connections.
> > > >>
> > > >> Thanks,
> > > >> Manikumar
> > > >>
> > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
> > > >>
> > > >> > Hi Mani,
> > > >> >              Overall KIP looks good to me. Can we call this
> > > >> Impersonation
> > > >> > support, which is what the KIP is doing?
> > > >> > Also instead of using super.uses as the config which essentially
> > > giving
> > > >> > cluster-wide support to the users, we can introduce
> > > impersonation.users
> > > >> as
> > > >> > a config and users listed in the config are allowed to impersonate
> > > other
> > > >> > users.
> > > >> >
> > > >> > Thanks,
> > > >> > Harsha
> > > >> >
> > > >> >
> > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > >> > > Bump up! to get some attention.
> > > >> > >
> > > >> > > BTW, recently Apache Spark added  support for Kafka delegation
> > > token.
> > > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > > >> > >
> > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> > manikumar.reddy@gmail.com
> > > >
> > > >> > wrote:
> > > >> > >
> > > >> > > > Bump up! to get some attention.
> > > >> > > >
> > > >> > > > BTW, recently Apache Spark added for Kafka delegation token
> > > support.
> > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > >> > > >
> > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > > >> manikumar.reddy@gmail.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > >> Hi all,
> > > >> > > >>
> > > >> > > >> I have created a KIP that proposes to allow users to create
> > > >> delegation
> > > >> > > >> tokens for other users.
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>
> > > >> >
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > >> > > >>
> > > >> > > >> Please take a look when you get a chance.
> > > >> > > >>
> > > >> > > >> Thanks,
> > > >> > > >> Manikumar
> > > >> > > >>
> > > >> > > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Hey Manikumar,

Thanks for the feedback.
I'm not sure I fully grasp the use-case. Would this be a quota? Do we say
something like "there can be 10 active delegation tokens at a time that is
created by superuserA for other users"?
I think such a feature could be useful to limit the responsibility of said
superuser (and blast radius in case of a faulty/malicious superuser) and
also to limit potential programming errors. Do you have other use cases too?

Thanks,
Viktor


On Tue, Aug 6, 2019 at 1:28 PM Manikumar <ma...@gmail.com> wrote:

> Hi Viktor,
>
> Thanks for taking over this KP.
>
> Current proposed ACL changes allows users to create tokens for any user.
> Thinking again about this, admins may want to configure a user to
> impersonate limited number of other users.
> This allows us to configure fine-grained permissions.  But this requires a
> new resourceType "User".  What do you think?
>
>
> Thanks,
> Manikumar
>
>
> On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com>
> wrote:
>
> > Hi Folks,
> >
> > I'm starting a vote on this.
> >
> > Viktor
> >
> > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> > viktorsomogyi@gmail.com> wrote:
> >
> > > Hi Folks,
> > >
> > > I took over this issue from Manikumar. Recently another motivation have
> > > been raised in Spark for this (SPARK-28173) and I think it'd be great
> to
> > > continue this task.
> > > I updated the KIP and will wait for a few days to get some feedback
> then
> > > proceed for the vote.
> > >
> > > Thanks,
> > > Viktor
> > >
> > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <ma...@gmail.com>
> > > wrote:
> > >
> > >> Hi Harsha,
> > >>
> > >> Thanks for the review.
> > >>
> > >> With this KIP a designated superuser can create tokens without
> requiring
> > >> individual user credentials.
> > >> Any client can authenticate brokers using the created tokens. We may
> not
> > >> call this as impersonation,
> > >> since the clients API calls are executing on their own authenticated
> > >> connections.
> > >>
> > >> Thanks,
> > >> Manikumar
> > >>
> > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
> > >>
> > >> > Hi Mani,
> > >> >              Overall KIP looks good to me. Can we call this
> > >> Impersonation
> > >> > support, which is what the KIP is doing?
> > >> > Also instead of using super.uses as the config which essentially
> > giving
> > >> > cluster-wide support to the users, we can introduce
> > impersonation.users
> > >> as
> > >> > a config and users listed in the config are allowed to impersonate
> > other
> > >> > users.
> > >> >
> > >> > Thanks,
> > >> > Harsha
> > >> >
> > >> >
> > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > >> > > Bump up! to get some attention.
> > >> > >
> > >> > > BTW, recently Apache Spark added  support for Kafka delegation
> > token.
> > >> > > https://issues.apache.org/jira/browse/SPARK-25501
> > >> > >
> > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <
> manikumar.reddy@gmail.com
> > >
> > >> > wrote:
> > >> > >
> > >> > > > Bump up! to get some attention.
> > >> > > >
> > >> > > > BTW, recently Apache Spark added for Kafka delegation token
> > support.
> > >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > >> > > >
> > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> > >> manikumar.reddy@gmail.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > >> Hi all,
> > >> > > >>
> > >> > > >> I have created a KIP that proposes to allow users to create
> > >> delegation
> > >> > > >> tokens for other users.
> > >> > > >>
> > >> > > >>
> > >> > > >>
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > >> > > >>
> > >> > > >> Please take a look when you get a chance.
> > >> > > >>
> > >> > > >> Thanks,
> > >> > > >> Manikumar
> > >> > > >>
> > >> > > >
> > >> >
> > >>
> > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Hi Viktor,

Thanks for taking over this KP.

Current proposed ACL changes allows users to create tokens for any user.
Thinking again about this, admins may want to configure a user to
impersonate limited number of other users.
This allows us to configure fine-grained permissions.  But this requires a
new resourceType "User".  What do you think?


Thanks,
Manikumar


On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass <vi...@gmail.com>
wrote:

> Hi Folks,
>
> I'm starting a vote on this.
>
> Viktor
>
> On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
> viktorsomogyi@gmail.com> wrote:
>
> > Hi Folks,
> >
> > I took over this issue from Manikumar. Recently another motivation have
> > been raised in Spark for this (SPARK-28173) and I think it'd be great to
> > continue this task.
> > I updated the KIP and will wait for a few days to get some feedback then
> > proceed for the vote.
> >
> > Thanks,
> > Viktor
> >
> > On Tue, Dec 11, 2018 at 8:29 AM Manikumar <ma...@gmail.com>
> > wrote:
> >
> >> Hi Harsha,
> >>
> >> Thanks for the review.
> >>
> >> With this KIP a designated superuser can create tokens without requiring
> >> individual user credentials.
> >> Any client can authenticate brokers using the created tokens. We may not
> >> call this as impersonation,
> >> since the clients API calls are executing on their own authenticated
> >> connections.
> >>
> >> Thanks,
> >> Manikumar
> >>
> >> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
> >>
> >> > Hi Mani,
> >> >              Overall KIP looks good to me. Can we call this
> >> Impersonation
> >> > support, which is what the KIP is doing?
> >> > Also instead of using super.uses as the config which essentially
> giving
> >> > cluster-wide support to the users, we can introduce
> impersonation.users
> >> as
> >> > a config and users listed in the config are allowed to impersonate
> other
> >> > users.
> >> >
> >> > Thanks,
> >> > Harsha
> >> >
> >> >
> >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> >> > > Bump up! to get some attention.
> >> > >
> >> > > BTW, recently Apache Spark added  support for Kafka delegation
> token.
> >> > > https://issues.apache.org/jira/browse/SPARK-25501
> >> > >
> >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <manikumar.reddy@gmail.com
> >
> >> > wrote:
> >> > >
> >> > > > Bump up! to get some attention.
> >> > > >
> >> > > > BTW, recently Apache Spark added for Kafka delegation token
> support.
> >> > > > https://issues.apache.org/jira/browse/SPARK-25501
> >> > > >
> >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
> >> manikumar.reddy@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > >> Hi all,
> >> > > >>
> >> > > >> I have created a KIP that proposes to allow users to create
> >> delegation
> >> > > >> tokens for other users.
> >> > > >>
> >> > > >>
> >> > > >>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> >> > > >>
> >> > > >> Please take a look when you get a chance.
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Manikumar
> >> > > >>
> >> > > >
> >> >
> >>
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Hi Folks,

I'm starting a vote on this.

Viktor

On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass <
viktorsomogyi@gmail.com> wrote:

> Hi Folks,
>
> I took over this issue from Manikumar. Recently another motivation have
> been raised in Spark for this (SPARK-28173) and I think it'd be great to
> continue this task.
> I updated the KIP and will wait for a few days to get some feedback then
> proceed for the vote.
>
> Thanks,
> Viktor
>
> On Tue, Dec 11, 2018 at 8:29 AM Manikumar <ma...@gmail.com>
> wrote:
>
>> Hi Harsha,
>>
>> Thanks for the review.
>>
>> With this KIP a designated superuser can create tokens without requiring
>> individual user credentials.
>> Any client can authenticate brokers using the created tokens. We may not
>> call this as impersonation,
>> since the clients API calls are executing on their own authenticated
>> connections.
>>
>> Thanks,
>> Manikumar
>>
>> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
>>
>> > Hi Mani,
>> >              Overall KIP looks good to me. Can we call this
>> Impersonation
>> > support, which is what the KIP is doing?
>> > Also instead of using super.uses as the config which essentially giving
>> > cluster-wide support to the users, we can introduce impersonation.users
>> as
>> > a config and users listed in the config are allowed to impersonate other
>> > users.
>> >
>> > Thanks,
>> > Harsha
>> >
>> >
>> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
>> > > Bump up! to get some attention.
>> > >
>> > > BTW, recently Apache Spark added  support for Kafka delegation token.
>> > > https://issues.apache.org/jira/browse/SPARK-25501
>> > >
>> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <ma...@gmail.com>
>> > wrote:
>> > >
>> > > > Bump up! to get some attention.
>> > > >
>> > > > BTW, recently Apache Spark added for Kafka delegation token support.
>> > > > https://issues.apache.org/jira/browse/SPARK-25501
>> > > >
>> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <
>> manikumar.reddy@gmail.com>
>> > > > wrote:
>> > > >
>> > > >> Hi all,
>> > > >>
>> > > >> I have created a KIP that proposes to allow users to create
>> delegation
>> > > >> tokens for other users.
>> > > >>
>> > > >>
>> > > >>
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
>> > > >>
>> > > >> Please take a look when you get a chance.
>> > > >>
>> > > >> Thanks,
>> > > >> Manikumar
>> > > >>
>> > > >
>> >
>>
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Viktor Somogyi-Vass <vi...@gmail.com>.
Hi Folks,

I took over this issue from Manikumar. Recently another motivation have
been raised in Spark for this (SPARK-28173) and I think it'd be great to
continue this task.
I updated the KIP and will wait for a few days to get some feedback then
proceed for the vote.

Thanks,
Viktor

On Tue, Dec 11, 2018 at 8:29 AM Manikumar <ma...@gmail.com> wrote:

> Hi Harsha,
>
> Thanks for the review.
>
> With this KIP a designated superuser can create tokens without requiring
> individual user credentials.
> Any client can authenticate brokers using the created tokens. We may not
> call this as impersonation,
> since the clients API calls are executing on their own authenticated
> connections.
>
> Thanks,
> Manikumar
>
> On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:
>
> > Hi Mani,
> >              Overall KIP looks good to me. Can we call this Impersonation
> > support, which is what the KIP is doing?
> > Also instead of using super.uses as the config which essentially giving
> > cluster-wide support to the users, we can introduce impersonation.users
> as
> > a config and users listed in the config are allowed to impersonate other
> > users.
> >
> > Thanks,
> > Harsha
> >
> >
> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > > Bump up! to get some attention.
> > >
> > > BTW, recently Apache Spark added  support for Kafka delegation token.
> > > https://issues.apache.org/jira/browse/SPARK-25501
> > >
> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <ma...@gmail.com>
> > wrote:
> > >
> > > > Bump up! to get some attention.
> > > >
> > > > BTW, recently Apache Spark added for Kafka delegation token support.
> > > > https://issues.apache.org/jira/browse/SPARK-25501
> > > >
> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <manikumar.reddy@gmail.com
> >
> > > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I have created a KIP that proposes to allow users to create
> delegation
> > > >> tokens for other users.
> > > >>
> > > >>
> > > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > > >>
> > > >> Please take a look when you get a chance.
> > > >>
> > > >> Thanks,
> > > >> Manikumar
> > > >>
> > > >
> >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Hi Harsha,

Thanks for the review.

With this KIP a designated superuser can create tokens without requiring
individual user credentials.
Any client can authenticate brokers using the created tokens. We may not
call this as impersonation,
since the clients API calls are executing on their own authenticated
connections.

Thanks,
Manikumar

On Fri, Dec 7, 2018 at 11:56 PM Harsha <ka...@harsha.io> wrote:

> Hi Mani,
>              Overall KIP looks good to me. Can we call this Impersonation
> support, which is what the KIP is doing?
> Also instead of using super.uses as the config which essentially giving
> cluster-wide support to the users, we can introduce impersonation.users as
> a config and users listed in the config are allowed to impersonate other
> users.
>
> Thanks,
> Harsha
>
>
> On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> > Bump up! to get some attention.
> >
> > BTW, recently Apache Spark added  support for Kafka delegation token.
> > https://issues.apache.org/jira/browse/SPARK-25501
> >
> > On Fri, Dec 7, 2018 at 5:27 PM Manikumar <ma...@gmail.com>
> wrote:
> >
> > > Bump up! to get some attention.
> > >
> > > BTW, recently Apache Spark added for Kafka delegation token support.
> > > https://issues.apache.org/jira/browse/SPARK-25501
> > >
> > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <ma...@gmail.com>
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> I have created a KIP that proposes to allow users to create delegation
> > >> tokens for other users.
> > >>
> > >>
> > >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> > >>
> > >> Please take a look when you get a chance.
> > >>
> > >> Thanks,
> > >> Manikumar
> > >>
> > >
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Harsha <ka...@harsha.io>.
Hi Mani,
             Overall KIP looks good to me. Can we call this Impersonation support, which is what the KIP is doing? 
Also instead of using super.uses as the config which essentially giving cluster-wide support to the users, we can introduce impersonation.users as a config and users listed in the config are allowed to impersonate other users.

Thanks,
Harsha
              

On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote:
> Bump up! to get some attention.
> 
> BTW, recently Apache Spark added  support for Kafka delegation token.
> https://issues.apache.org/jira/browse/SPARK-25501
> 
> On Fri, Dec 7, 2018 at 5:27 PM Manikumar <ma...@gmail.com> wrote:
> 
> > Bump up! to get some attention.
> >
> > BTW, recently Apache Spark added for Kafka delegation token support.
> > https://issues.apache.org/jira/browse/SPARK-25501
> >
> > On Tue, Sep 25, 2018 at 9:56 PM Manikumar <ma...@gmail.com>
> > wrote:
> >
> >> Hi all,
> >>
> >> I have created a KIP that proposes to allow users to create delegation
> >> tokens for other users.
> >>
> >>
> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
> >>
> >> Please take a look when you get a chance.
> >>
> >> Thanks,
> >> Manikumar
> >>
> >

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Bump up! to get some attention.

BTW, recently Apache Spark added  support for Kafka delegation token.
https://issues.apache.org/jira/browse/SPARK-25501

On Fri, Dec 7, 2018 at 5:27 PM Manikumar <ma...@gmail.com> wrote:

> Bump up! to get some attention.
>
> BTW, recently Apache Spark added for Kafka delegation token support.
> https://issues.apache.org/jira/browse/SPARK-25501
>
> On Tue, Sep 25, 2018 at 9:56 PM Manikumar <ma...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I have created a KIP that proposes to allow users to create delegation
>> tokens for other users.
>>
>>
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
>>
>> Please take a look when you get a chance.
>>
>> Thanks,
>> Manikumar
>>
>

Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users

Posted by Manikumar <ma...@gmail.com>.
Bump up! to get some attention.

BTW, recently Apache Spark added for Kafka delegation token support.
https://issues.apache.org/jira/browse/SPARK-25501

On Tue, Sep 25, 2018 at 9:56 PM Manikumar <ma...@gmail.com> wrote:

> Hi all,
>
> I have created a KIP that proposes to allow users to create delegation
> tokens for other users.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users
>
> Please take a look when you get a chance.
>
> Thanks,
> Manikumar
>