Add beta field to Secrets Manager enrollment queries

Erick Bajaorequested to merge
eb-beta-field-sm-enrollment-query into master

What does this MR do and why?

This MR adds a beta field to both Secrets Manager enrollment GraphQL queries. The frontend needs this field to tell the free beta cohort apart from later cohorts.

On the namespace side, the SecretsManagerEnrollment type gets a new beta (Boolean!) field. It reads the beta column added in !249180 (merged).

On the instance side, Query.instanceSecretsManagerEnrollment used to return a plain Boolean. It now returns a new type, SecretsManagerInstanceEnrollment, with two fields: enrolled and beta.

For instance beta identification, there is no general availability setting yet. Following the approach agreed on the work item, the existing secrets_manager_instance_enrolled application setting is used as the beta marker. SecretsManagement::InstanceEnrollment.beta? currently just returns enrolled?. A code comment records the follow-up: when GA ships, add a secrets_manager_instance_ga_enrolled setting and return enrolled? && !ga_enrolled?.

Frontend changes are only what the type change forces. The admin toggle query now selects { enrolled beta } and the component reads ?.enrolled. There is no new UI behavior, and nothing reads beta yet.

Why reshape the instance query

We changed the field type instead of adding a second top-level Boolean field, such as instanceSecretsManagerEnrollmentBeta.

  • One field per concept is cleaner, and it mirrors the namespace query, which already returns an object.
  • This leaves room to add more enrollment attributes later without adding more top-level query fields.
  • The field is marked experiment: { milestone: '19.0' }, so changing its type does not need a deprecation cycle.

Deploy safety

We checked that this reshape cannot break GitLab.com. The admin toggle that sends this query only renders on self-managed. The partial ee/app/views/admin/application_settings/_secrets_manager_instance_enrollment.html.haml returns early unless allow_secrets_manager_instance_enrollment?, which requires !Gitlab.com?.

On self-managed, the package upgrades backend and frontend assets together, so there is no version skew. The only affected case is an admin who left the settings page open across an upgrade. A page refresh fixes it.

Third-party clients that query the field as a scalar would break, but the field is an experiment field and is admin only, so the exposure is small.

Granular token authorization

New GraphQL object types must declare authorize_granular_token. The pre-push permissions validation catches this if it is missing.

We added authorize_granular_token permissions: :read_secrets_manager_enrollment, boundary: :instance, boundary_type: :instance to the new type.

The raw permission read_secrets_manager_enrollment already existed, but it was not part of any assignable permission. This MR adds config/authz/permission_groups/assignable_permissions/secrets_management/secrets_manager_enrollment/read.yml with boundaries: [instance] and available_for: [granular_access_token].

Worth calling out for the reviewer: this makes "read Secrets Manager enrollment status" a grantable fine-grained token permission at instance level. Removing an assignable permission later is a breaking change for token holders.

The older SecretsManagerEnrollment type and the four enrollment mutations predate this requirement, so they stay grandfathered in config/authz/graphql/authorization_todo.txt. New entries cannot be added to that file. Adding the directive to the namespace type is a natural follow-up. It would reuse the same assignable permission file and add group to its boundaries list.

We regenerated doc/auth/tokens/fine_grained_access_tokens_graphql.md with bundle exec rake gitlab:permissions:graphql:compile_docs.

We also added the required authorization spec using the shared example authorizing granular token permissions for GraphQL.

Database

No database changes. The beta column already exists from !249180 (merged).

Backward compatibility and rollback

The namespace change is purely additive.

The instance change is a type change on an experiment field. See the deploy safety notes above for why this is safe.

Rollback is a plain revert. No data changes are involved.

How to set up and validate locally

Instance enrollment is self-managed only, so do not simulate SaaS for it. The instance also needs the native_secrets_management licensed feature and the secrets_manager_instance_enrollment feature flag.

  1. Run the specs:

    bundle exec rspec \
  ee/spec/requests/api/graphql/secrets_management/instance_enrollment_query_spec.rb \
  ee/spec/requests/api/graphql/secrets_management/namespace_enrollment_query_spec.rb \
  ee/spec/models/secrets_management/instance_enrollment_spec.rb

  2. Run the frontend spec:

    yarn jest ee/spec/frontend/admin/application_settings/general/secrets_manager_instance_enrollment

  3. Confirm the permissions validation passes:

    bundle exec rake gitlab:permissions:validate

  4. Enroll the instance, either with the admin settings toggle or from the console:

    user = User.admins.first
SecretsManagement::InstanceEnrollmentService.new(current_user: user).enroll

  5. Query it in GraphiQL as an admin. Both fields return true once the instance is enrolled:

    query {
  instanceSecretsManagerEnrollment {
    enrolled
    beta
  }
}

  6. For the namespace side, query on a GitLab.com simulation against an enrolled top-level group:

    query {
  namespaceSecretsManagerEnrollment(namespacePath: "flightjs") {
    namespace {
      fullPath
    }
    beta
  }
}

References

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 Erick Bajao

Merge request reports