+1 non-binding
Ryanne
On Tue, Sep 10, 2019, 7:51 AM Viktor Somogyi-Vass
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
> wrote:
>
> > +1 (non-binding) I've had a deeper look and this would be a good
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
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 <
>
+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
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
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
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
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
wrote:
> Hi Manikumar,
>
> Yea, I just brought up superuser for
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"
+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
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
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
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
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
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,
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
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
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 wrote:
> Bump up! to get some attention.
>
> BTW, recently Apache Spark added for Kafka delegation
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 wrote:
> Hi all,
>
> I have created a KIP that proposes to allow users to create delegation
> tokens
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
18 matches
Mail list logo
