Declare assignable_when conditions on the admin token API

What does this MR do and why?

This MR is one of seven that split !253276 (merged) into pieces that each need only Authorization approval plus at most one other CODEOWNERS section. This one needs Authorization and Authentication.

A consumer earns a condition tag only when it rejects every request from a caller who does not meet the condition, for every parameter. Partial checks, feature flags, and license checks do not count. The admin condition covers authenticated_as_admin! checks and admin-only global abilities. Nothing changes at request time. The only effect is that the token creation UI stops offering a permission at boundaries where the current user does not meet the condition.

This MR tags the 1 REST consumer (lib/api/admin/token.rb, its POST and DELETE routes) with the admin condition, 2 tags in total. 2 YAML files gain assignable_when: admin: system_access/any_token/read and system_access/any_token/revoke.

References

• Original MR being split: !253276 (merged)
• Parent MR that added GraphQL assignable_when support: !253246 (merged)
• MR that introduced assignable_when for REST endpoints: !246776 (merged)
• Sibling MRs from the same split:
  • !253276 (merged) (Declare admin assignable_when conditions on granular token consumers)
  • !255011 (merged) (Declare SaaS and self-managed assignable_when conditions)
  • !255014 (merged) (Declare assignable_when conditions on Geo granular token consumers)
  • !255015 (merged) (Declare assignable_when conditions on system hook consumers)
  • !255017 (merged) (Declare assignable_when conditions on the experiments API)
  • !255022 (merged) (Declare assignable_when conditions on CI granular token consumers)

Screenshots or screen recordings

No UI changes in this MR.

How to set up and validate locally

1. Run bundle exec rake gitlab:permissions:validate. It passes.

2. Remove the assignable_when: block from config/authz/permission_groups/assignable_permissions/system_access/any_token/revoke.yml and run the task again. It fails and lists the consumer in lib/api/admin/token.rb with Consumer conditions: [admin]. Restore the block.

3. Enable the granular_personal_access_tokens feature flag, then query the GraphQL accessTokenPermissions field (or open the fine-grained token creation page) as a regular user and as an administrator, and compare the boundaries returned for revoke_any_token. The regular user does not get INSTANCE.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.