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