Access Denied when updating access token

[nreisingercres]

I'm not sure if this belongs here or in the main repo, but I see the issue in the console.

Expected Behavior

I should have access to update my own token.

Current Behavior

Access is denied when pressing update

Possible Solution

Give users permission to update their own access tokens

Steps to Reproduce (for bugs)

1. Create a user without admin:UpdateServiceAccount (I tested with the default readonly role)
2. From the console, use that user to create an access token
3. Again from the console, use that user to try and update the token

Context

I am trying to update an access token without recreating it.

Regression

I don't think so.

Your Environment

• MinIO version used (minio --version):

minio version RELEASE.2024-09-22T00-33-43Z (commit-id=03e996320ebb887112fb2a15c6f27936e5f124a0)
Runtime: go1.22.7 linux/amd64
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Copyright: 2015-2024 MinIO, Inc.

• Server setup and configuration: Running in podman across 3 servers.
• Operating System and version (uname -a): Linux minio 6.1.0-25-amd64 minio/console#1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 x86_64 x86_64 GNU/Linux

[ramondeklein]

Tested and confirmed that users cannot update access-tokens that they have created.

[bexsoft]

@nreisingercres Have you tried to update the session token by using mc?

@ramondeklein Do you think this issue belongs to Console or should it be moved to MinIO repository?

[nreisingercres]

@nreisingercres Have you tried to update the session token by using mc?

I just tried using mc admin user svcacct edit and I got mc: <ERROR> Unable to edit the specified service account. Access Denied.

[ramondeklein]

Do you think this issue belongs to Console or should it be moved to MinIO repository?

I think it's caused by MinIO security checks. If we do want to allow this, then it should be fixed in MinIO. The console is only reporting the error that MinIO generates.

[harshavardhana]

you cannot just keep extending your own access forever, that is a security nightmare, a random service account should never get higher privileges in this manner.

[harshavardhana]

• Create a user without admin:UpdateServiceAccount (I tested with the default readonly role)

Since you don't have the access to update your own service account which is denied here the error is valid.

[taran-p]

Looks like this was intentionally changed 8 months ago pending some redesign

minio/cmd/admin-handlers-users.go

Lines 847 to 849 in ba70118

	// 2. We would like to let a user update their own access keys, however it
	// is currently blocked pending a re-design. Users are still able to delete
	// and re-create them.

Given we currently allow a user to delete and recreate the access key anyway, it might make sense to have the permission check be deny only like how it is when creating a service account for oneself. @harshavardhana

[harshavardhana]

@donatello ^^ added this - can you chime in here?

[donatello]

This was the PR that added this restriction #18928 - the reason is that service accounts being able to update their own permissions was a previous security issue. A common use case for service accounts is for an administrator to create a restricted service account and give only those credentials to an app or person - clearly that service account should not be able to escalate its permissions. Having to configure an explicit deny only statement in the policy to prevent this was not an effective way as it becomes an insecure by default setting.

To cleanly allow a user to be able to update their owned service accounts requires adding some user level permissions (in contrast the existing admin:UpdateServiceAccount permission that is intended for administrators) - we will discuss internally on this.

In the meanwhile @nreisingercres - you can still remove and re-create the service account with the same settings with whatever updates you need.

[harshavardhana]

Closing this since remove and recreate is what is recommended here for now.

// Cc @ravindk89