Hi Rajini & Ron,
Thanks, this is an interesting discussion.
I think Ron made a good point earlier that if you have ALTER on CLUSTER then
you can give yourself whatever other ACLs you want. And this is true even if
you are authenticated via a delegation token. So splitting the ability to
alte
Hi Ron,
Sounds good to me, thank you.
Regards,
Rajini
On Wed, Sep 2, 2020 at 8:00 PM Ron Dagostino wrote:
> Thanks, Rajini. That's a good point about authorizing user creation and
> ACL creation separately to enable that separation as an *option* -- I agree
> with that, which I think argues
Thanks, Rajini. That's a good point about authorizing user creation and
ACL creation separately to enable that separation as an *option* -- I agree
with that, which I think argues for a separate ALTER_USER operation (or
ALTER_USER_CREDENTIAL operation; not sure what the best name is, but
probably
Hi Ron,
Not sure the person who creates/manages users is always the person who
controls access to Kafka resources. Separate ACLs gives the flexibility to
keep them separate while you can still grant both to the user, while a
combined ACL means that they can only be granted together. A related
ques
Hi Rajini. Thanks for the explanation.
I think these are the APIs that are authorized via the ALTER CLUSTER
operation, none of which are restricted when authenticating via delegation
token:
ALTER_PARTITION_REASSIGNMENTS
ALTER_REPLICA_LOG_DIRS
CREATE_ACL
DELETE_ACL
ELECT_LEADERS
I think if we ar
Hi Ron/Colin,
Without any restrictions, if delegation tokens can be used to create new
users or change the password of the user you are impersonating, you also
get the power to create/renew a new token by authenticating as a SCRAM user
you just created or updated. It seems like a new power that we
Hi Ron,
Thanks. We can wait for Rajini's reply to finalize this, but for now I guess
that will unblock the PR at least. If we do decide we want the restriction we
can do a follow-on PR.
It's good to see this API moving forward!
best,
Colin
On Tue, Sep 1, 2020, at 12:55, Ron Dagostino wrote
Hi Colin. I've removed that requirement from the KIP and updated the PR
accordingly.
Ron
On Fri, Aug 28, 2020 at 2:27 PM Colin McCabe wrote:
> Hi Ron,
>
> Thanks for the update. I agree with all of these changes, except I think
> we should discuss this one further:
>
> On Wed, Aug 26, 2020, a
Hi Ron,
Thanks for the update. I agree with all of these changes, except I think we
should discuss this one further:
On Wed, Aug 26, 2020, at 14:59, Ron Dagostino wrote:
>
> 2. We added a restriction to not allow users who authenticated using
> delegation tokens to create or update user SCRAM c
Hi everyone. Multiple changes came up during the discussion of the PR for
KIP-554 (https://github.com/apache/kafka/pull/9032). I will update the KIP
soon (likely tomorrow) but wanted to send notification to this email thread
in case anyone wishes to discuss the changes. They are as follows:
1.
Thanks, Ron. Sounds good.
best,
Colin
On Tue, Jul 28, 2020, at 15:26, Ron Dagostino wrote:
> Hi everyone. I just wanted to notify that while implementing this I
> discovered that we had declared the ScramMechanism enum to have the values
> HMAC_SHA_{256,512} instead of SCRAM_SHA_{256,512}. I b
Hi everyone. I just wanted to notify that while implementing this I
discovered that we had declared the ScramMechanism enum to have the values
HMAC_SHA_{256,512} instead of SCRAM_SHA_{256,512}. I believe Rajini had
indicated that this should be changed back on May 7th, and the change makes
sense
Hi all,
With binding +1s from Rajini Sivaram, David Arthur, and Boyang Chen, and
non-binding +1s from Tom Bentley, the vote passes.
Thanks to everyone who commented and helped to improve the proposal, especially
Ron Dagostino, David, and Boyang.
best,
Colin
On Thu, Jul 16, 2020, at 16:02, Ro
Hi Colin. I updated the KIP with various renames. I've also created a
draft PR at https://github.com/apache/kafka/pull/9032 that still needs a
bunch of real implementation but nonetheless represents the renames in code.
The biggest changes are that there are now derived classes public class
User
On Thu, Jul 16, 2020, at 08:06, Ron Dagostino wrote:
> Thanks, Colin. The standard "about" message for ThrottleTimeMs seems
> to be "The duration in milliseconds for which the request was throttled
> due to a quota violation, or zero if the request did not violate any quota."
> as opposed to "The
Thanks, Colin. The standard "about" message for ThrottleTimeMs seems
to be "The
duration in milliseconds for which the request was throttled due to a quota
violation, or zero if the request did not violate any quota." as
opposed to "The
time spent waiting for quota." Should we adjust to match the
Hi all,
Thanks, everyone, for reviewing.
Since we made a few changes to the RPCs in the last few days, I'm going to
extend the vote until Monday and close it out then if it looks good.
best,
Colin
On Wed, Jul 15, 2020, at 14:47, Colin McCabe wrote:
> On Tue, Jul 14, 2020, at 16:23, Ron Dagost
On Tue, Jul 14, 2020, at 16:23, Ron Dagostino wrote:
> Thanks, Colin.
>
> DescribeScramUsersResponse returns a list of ScramUser instances, which
> makes sense, but then each of the ScramUser instances only has a single
> ScramUserMechanismInfo instance. I believe it needs a List of those?
Hi Ro
Hi again, Colin.
I believe the below function should refer to List
alterations in its signature and should invoke alterScramUsers(alterations,
new AlterScramUsersOptions()), correct?
default AlterScramUsersResult alterScramUsers(List
alterations) {
return alterScramUsers(deletions, alteration
Thanks, Colin.
DescribeScramUsersResponse returns a list of ScramUser instances, which
makes sense, but then each of the ScramUser instances only has a single
ScramUserMechanismInfo instance. I believe it needs a List of those?
Also, ScramUserMechanismInfo probably needs a better "about" value (i
On Tue, Jul 14, 2020, at 07:57, Ron Dagostino wrote:
> Hi again, Colin. I also just realized a couple of other incompatibilities
> with the way kafka-configs works today that prevents --bootstrap-server
> from being a drop-in replacement. This may or may not be a hard
> requirement, but we should
Hi again, Colin. I also just realized a couple of other incompatibilities
with the way kafka-configs works today that prevents --bootstrap-server
from being a drop-in replacement. This may or may not be a hard
requirement, but we should explicitly decide on these one way or the other.
One issue
Hi Colin. I wanted to explicitly identify a side-effect that I think
derives from having deletions separated out from the AlterScramUsersRequest
and put in their own DeleteScramUsersRequest. The command line invocation
of kafka-configs can specify alterations and deletions simultaneously: it
is en
Thanks for the clarification, Colin. +1 binding from me
-David
On Mon, Jul 13, 2020 at 3:40 PM Colin McCabe wrote:
> Thanks, Boyang. Fixed.
>
> best,
> Colin
>
> On Mon, Jul 13, 2020, at 08:43, Boyang Chen wrote:
> > Thanks for the update Colin. One nit comment to fix the RPC type
> > for Alte
Thanks, Boyang. Fixed.
best,
Colin
On Mon, Jul 13, 2020, at 08:43, Boyang Chen wrote:
> Thanks for the update Colin. One nit comment to fix the RPC type
> for AlterScramUsersRequest as:
> "apiKey": 51,
> "type": "request",
> "name": "AlterScramUsersRequest",
> Other than that, +1 (binding) from
Thanks for the update Colin. One nit comment to fix the RPC type
for AlterScramUsersRequest as:
"apiKey": 51,
"type": "request",
"name": "AlterScramUsersRequest",
Other than that, +1 (binding) from me.
On Mon, Jul 13, 2020 at 8:38 AM Colin McCabe wrote:
> Hi David,
>
> The API is for clients.
Hi David,
The API is for clients. Brokers will still listen to ZooKeeper to load the
SCRAM information.
best,
Colin
On Mon, Jul 13, 2020, at 08:30, David Arthur wrote:
> Thanks for the KIP, Colin. The new RPCs look good to me, just one question:
> since we don't return the password info throu
Thanks for the KIP, Colin. The new RPCs look good to me, just one question:
since we don't return the password info through the RPC, how will brokers
load this info? (I'm presuming that they need it to configure
authentication)
-David
On Mon, Jul 13, 2020 at 10:57 AM Colin McCabe wrote:
> On Fr
On Fri, Jul 10, 2020, at 10:55, Boyang Chen wrote:
> Hey Colin, thanks for the KIP. One question I have about AlterScramUsers
> RPC is whether we could consolidate the deletion list and alteration list,
> since in response we only have a single list of results. The further
> benefit is to reduce un
+1 (non-binding), thanks for the KIP.
On Fri, Jul 10, 2020 at 7:02 PM Boyang Chen
wrote:
> Hey Colin, thanks for the KIP. One question I have about AlterScramUsers
> RPC is whether we could consolidate the deletion list and alteration list,
> since in response we only have a single list of resul
Hey Colin, thanks for the KIP. One question I have about AlterScramUsers
RPC is whether we could consolidate the deletion list and alteration list,
since in response we only have a single list of results. The further
benefit is to reduce unintentional duplicate entries for both deletion and
alterat
+1 (binding)
Thanks for the KIP, Colin!
Regards,
Rajini
On Thu, Jul 9, 2020 at 8:49 PM Colin McCabe wrote:
> Hi all,
>
> I'd like to call a vote for KIP-554: Add a broker-side SCRAM configuration
> API. The KIP is here: https://cwiki.apache.org/confluence/x/ihERCQ
>
> The previous discussio
32 matches
Mail list logo
