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 > > > > > >
