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 question is about password change. In the current model, User:Alice authenticated as Alice cannot change Alice's password without Alter permissions on the Cluster. The delegation token model where a user has more control over their own credential seems more appropriate in this case. Not sure if we considered and rejected that approach.
On Wed, Sep 2, 2020 at 5:57 PM Ron Dagostino <rndg...@gmail.com> wrote: > 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 are going to ALTER_USER_SCRAM_CREDENTIALS then we are likely > going to want to CREATE_ACL as well -- it feels like there's no sense in > creating a user but then not being able to authorize the user to do > anything. (Unless I am wrong here?). If this is correct, then > following that to its logical conclusion, it feels like we should authorize > ALTER_USER_SCRAM_CREDENTIALS via the same ALTER CLUSTER operation. And > then with respect to delegation tokens, I think we would either need to > allow delegation tokens to do both or we should prevent delegation tokens > from altering credentials. And then that gets to Colin's point about > whether sessions authenticated via delegation token should be second-class > in some way, which I am inclined to think they should not. > > Ron > > > On Wed, Sep 2, 2020 at 11:23 AM Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > 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 are > granting > > in a new API using an existing ACL. User management is a new class of > > operations we are adding to the Kafka protocol. An alternative to > > restricting delegation tokens would be to add a new ACL operation instead > > of reusing `Alter` for user management : `AlterUsers/DescribeUsers` (like > > AlterConfigs/DescribeConfigs). > > > > Regards, > > > > Rajini > > > > > > On Wed, Sep 2, 2020 at 12:24 AM Colin McCabe <co...@cmccabe.xyz> wrote: > > > > > 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 <cmcc...@apache.org> > > 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, 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 credentials. We > > > don't > > > > > > allow such authenticated users to create new tokens, and it would > > be > > > odd > > > > > if > > > > > > they could create a new user or change the password of the user > for > > > the > > > > > > token. > > > > > > > > > > > > > > > > I don't think these two restrictions are comparable. It seems to > me > > > that > > > > > we forbid creating a new token based on an existing token in order > to > > > force > > > > > users of delegation tokens to re-authenticate periodically through > > the > > > > > regular auth system. If they could just create a new token based > on > > > their > > > > > old token, there would be an obvious "wishing for more wishes" > > problem > > > and > > > > > they could just sidestep the regular authentication system entirely > > > once > > > > > they had a token. > > > > > > > > > > This issue doesn't exist here, since creating a new SCRAM user > > doesn't > > > do > > > > > anything to extend the life of the existing delegation token. If > the > > > user > > > > > has the permission to change SCRAM users, I don't see any reason > why > > we > > > > > should forbid them from doing just that. Users of delegation > tokens > > > > > shouldn't be second-class citizens. A user with ALTER on CLUSTER > > should > > > > > have all the permissions associated with ALTER on CLUSTER, > regardless > > > of if > > > > > they logged in with Kerberos, delegation tokens, SCRAM, etc. etc. > I > > > don't > > > > > think the proposed restriction you mention here is consistent with > > > that. > > > > > > > > > > best, > > > > > Colin > > > > > > > > > > > > > > >
