Declare SaaS and self-managed assignable_when conditions

Alex Buijsrequested to merge
feature/assignable-when-saas-self-managed into master

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 saas and self_managed conditions cover Gitlab.com? and Gitlab::Saas.feature_available? guards and their inverse. The admin condition covers authenticated_as_admin! checks, and several consumers here carry both an admin tag and a saas or self_managed tag. 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 18 consumers (42 tags) with saas, self_managed, and admin conditions: GraphQL mutations for member role create, delete, and update, Duo model selection allowlist updates, organization creation, subscription activation, and billable promotion requests, plus GraphQL types for model selection allowlists and secrets manager instance enrollment, and REST endpoints for member roles, the Manage API groups endpoint, Google Cloud integration, security scans, namespaces, subscriptions, and organizations. 21 YAML files gain assignable_when, mostly under system_access (5, personal access tokens and ssh keys), subscription_and_licensing (6), groups (5, member roles and namespace), and duo (2, model selection allowlist), plus one file each under application_security, organizations, and secrets_management. Most of the 42 tags are saas (22) or admin (10). Six pairs need both admin and self_managed, three need both admin and saas, and one is self_managed alone.

Two RSpec examples change to match. spec/features/user_settings/granular_personal_access_tokens/token_creation_spec.rb no longer expects Member Role among the Groups resources, and spec/features/user_settings/granular_personal_access_tokens/token_duplication_spec.rb's source token now uses SSH Certificate read and create instead of member role permissions, because member role permissions at the group boundary become GitLab.com-only.

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

Instance GET /member_roles and GET /admin_member_roles stay untagged, because the shared helper switches to a group-level check whenever an id query parameter is present.

References

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/groups/member_role/create.yml and run the task again. It fails and lists the GraphQL and REST member role creation consumers, with Consumer conditions: [saas] for the group boundary and Consumer conditions: [admin, self_managed] for the instance boundary. 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) for create_member_role. The saas boundary only appears in the boundaries returned on GitLab.com, not on a self-managed 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.

Edited by Alex Buijs

Merge request reports