kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viktor Somogyi-Vass <viktorsomo...@gmail.com>
Subject Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
Date Thu, 15 Aug 2019 16:19:28 GMT
Started to implement my proposition and thought about it a little bit more
and it seems like I overthought the problem and we'd actually be better off
by having only the User resource type only and not CreateUsers. The problem
with CreateUsers is that a resource apparently is created only in addAcls
(at least in SimpleAclAuthorizer). Therefore we'd need to check before
creating the token that the owner user has been created and the token
creator has the permissions. Then add the user resource and the token. This
means that we'd only use CreateUsers when creating tokens iff the token
requester principal already has CreateTokens permissions with that user
(the owner) so it's kinda duplicate.
It would work though if we require the resources to be added beforehand but
it's not the case and is the detail of the Authorizer implementation.

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

Thanks,
Viktor

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

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message