Root user cannot rotate principal credentials

[Gerrit-K]

Describe the bug

When trying to rotate a principal's credentials via the root user, an HTTP error with code 403 is returned:

{"error":{"message":"Principal 'root' with activated PrincipalRoles '[]' and activated grants via '[service_admin]' is not authorized for op ROTATE_CREDENTIALS","type":"ForbiddenException","code":403}}

To Reproduce

1. Deploy locally via docker compose up --build
2. Note down the root principal credentials and store them in a shell variable, e.g.

   CLIENT_ID=f69f1990657205d9
   CLIENT_SECRET=e89026b4e87d60b7bd6ea75adb16e6f8

3. Get an access token for the root principal

   TOKEN="$(curl --request POST "http://localhost:8181/api/catalog/v1/oauth/tokens?grant_type=client_credentials&scope=PRINCIPAL_ROLE%3AALL&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}" \
   --header 'content-type: application/x-www-form-urlencoded' \
   | jq -r .access_token)"

4. Create a new principal

   curl --request POST http://localhost:8181/api/management/v1/principals \
   --header "Authorization: Bearer $TOKEN" \
   --header "Content-Type: application/json" \
   -d '{"name": "test"}')"

5. Try to rotate the credentials of the new principal using the same token as it was created with

   curl --request POST http://localhost:8181/api/management/v1/principals/test/rotate \
   --header "Authorization: Bearer $TOKEN"

Actual Behavior

The service returns a 403 response

{"error":{"message":"Principal 'root' with activated PrincipalRoles '[]' and activated grants via '[service_admin]' is not authorized for op ROTATE_CREDENTIALS","type":"ForbiddenException","code":403}}

Expected Behavior

The principal credentials should successfully be rotated

Additional context

No response

System information

No response

[eric-maynard]

IIRC this is by design, users can rotate their own credentials but root cannot change them.

[Gerrit-K]

Hm, that seems a bit strange to me, to be honest 🤔 A not-so-rare use case for secret rotation is to restore access after credentials have been lost (by whatever means). If the root principal cannot do this, then there is literally no way to recover credentials, so the principal needs to be deleted and a new one set up, including setting up all the roles and permissions.

[dimas-b]

I agree with @Gerrit-K . Having "root" capable of resetting any principal's passwords is a valuable feature (whether it falls under the "rotate credentials" API or gets a new API endpoint).

[eric-maynard]

See #1047

[Gerrit-K]

@eric-maynard Thanks for the update! Reading through that PR description, I'm curious about the rationale behind this seemingly complex workflow. I'm not very familiar with the architecture of Polaris and the permission concept, so this might be a dumb question, but what speaks against directly allowing the root user to rotate (instead of reset) another principal's credentials? I don't see a benefit of this 2-step flow, at least from a security perspective.

[dimas-b]

After #2197 it seems that only CLI support needs to be added in order to resolve this issue :)

[binarycat0]

After #2197 it seems that only CLI support needs to be added in order to resolve this issue :)

Hello. I checked the current CLI principals sub-commands, seems to be this functionality already implemented. I tested it - works for me well.

    reset
      Named arguments:
        --new-client-id  The new client ID for the principal
        --new-client-secret  The new client secret for the principal
      Positional arguments:
        principal
    rotate-credentials
      Positional arguments:
        principal

[dimas-b]

Yes, reset was added in #2698... Closing this issue.