Declare admin assignable_when conditions on granular token consumers

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

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 consumers in 92 files (214 tags) with the admin condition: 47 GraphQL mutations and types (audit event streaming destinations, subscription add-on assignments and budget caps, admin member roles, LDAP admin role links, organization restore, custom attributes) and 45 REST API files (admin API surfaces including broadcast messages, batched background migrations and operations, plan limits, sidekiq admin, snippets, groups, projects, and users). 127 YAML files gain assignable_when: admin, concentrated in system_access (43 files, covering users, tokens, keys, and application settings), groups (16, covering admin member roles, GPG keys, LDAP admin role links, and topics), search (13, covering Zoekt and ActiveContext admin surfaces), subscription_and_licensing (11), project_planning (6), and ci_cd (7), plus smaller sets under compliance, geo, system_migration, notifications, orbit, project_features, integrations, monitoring, application_security, duo, organizations, and projects.

spec/features/user_settings/granular_personal_access_tokens/token_creation_spec.rb also changes. The Global tab CI/CD example now picks Runner instead of Cluster, because read_cluster at the instance boundary becomes admin-only.

system_access/ssh_key/delete.yml also picks up an admin condition at the instance boundary here. The saas-self-managed MR adds a separate saas condition at the group boundary to the same file. Whichever of the two merges second will need to rebase and merge both entries.

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:
  • !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)
  • !255016 (merged) (Declare assignable_when conditions on the admin token API)
  • !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/compliance/audit_event/read.yml and run the task again. It fails and lists the instance route in ee/lib/api/audit_events.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 read_audit_event. 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.