Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
+1 non-binding Ryanne On Tue, Sep 10, 2019, 7:51 AM Viktor Somogyi-Vass 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 > 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 < > > viktorsomo...@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 < > > > viktorsomo...@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 > > > > > 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 < > > > >> viktorsomo...@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 > > > >> 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 > > > >> > > >
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
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 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 < > viktorsomo...@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 < > > viktorsomo...@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 > > > 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 < > > >> viktorsomo...@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 > > >> 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"? > > >> > > > > > >>
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
+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 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 < > viktorsomo...@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 > > 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 < > >> viktorsomo...@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 > >> 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 < > >> > > viktorsomo...@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
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
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 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 > 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 < >> viktorsomo...@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 >> 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 < >> > > viktorsomo...@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, >> > > >
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
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 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 < > viktorsomo...@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 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 < > > > viktorsomo...@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.re...@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 < > > > > > > viktorsomo...@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 < > > > > > > > viktorsomo...@gmail.com> wrote: > > > > > > > > > > > > > > > Hi Folks, > > > > > > > > > >
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
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 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 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 < > > viktorsomo...@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 > > > > 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 < > > > > > viktorsomo...@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 < > > > > > > viktorsomo...@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.re...@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 > wrote: > > > > > > >> > > > > > > >> > Hi Mani, > > > > > > >> > Overall KIP looks good to me. Can we call this > > > > > > >> Impersonation
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
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 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 < > viktorsomo...@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 > > > 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 < > > > > viktorsomo...@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 < > > > > > viktorsomo...@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.re...@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 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
Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
+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 > 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 > > 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 < > > > viktorsomo...@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 < > > > > viktorsomo...@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 > > > > > > > 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 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.re...@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.re...@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
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 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 > 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 < > > viktorsomo...@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 < > > > viktorsomo...@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 > > > > > 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 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.re...@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.re...@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
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 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 < > viktorsomo...@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 < > > viktorsomo...@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 > > > 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 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.re...@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.re...@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
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 wrote: > Hi Folks, > > I'm starting a vote on this. > > Viktor > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass < > viktorsomo...@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 > > 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 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 > > >> > 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.re...@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
Hi Folks, I'm starting a vote on this. Viktor On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass < viktorsomo...@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 > 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 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 >> > 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.re...@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
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 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 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 > > 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 > > > > > 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
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 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 > 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 > > > 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
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 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 > > 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
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 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 > 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
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 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 >