kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabor Somogyi <gabor.g.somo...@gmail.com>
Subject Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users
Date Tue, 03 Sep 2019 11:49:09 GMT
+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 <viktorsomogyi@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 <
> 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