+1 non-binding Ryanne
On Tue, Sep 10, 2019, 7:51 AM Viktor Somogyi-Vass <viktorsomo...@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 <gabor.g.somo...@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 < > > 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 <manikumar.re...@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 < > > > >> 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 <cmcc...@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 < > > > >> > > 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, > > > >> > > > > > > > > > > >> > > > > > > > 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 < > > 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.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 > > > >> > > > > > > >> > > >> > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > > > > > >> > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > >
