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 > > >> > > > > > > >> > > >> > > >> > > > > > > >> > > > > > >> > > > > > > >> > > > >> > > > > > > >> > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > >
