Use Reporter as the no-grant principal in secrets specs

Chaya Danzingerrequested to merge
623438-spec-reporter-no-grant into master

What does this MR do and why?

This MR changes test code only. It updates six spec files. The diff has 14 insertions and 29 deletions. No production code changes.

Several spec contexts use a project role to stand in for a user who holds the GitLab ability to act on secrets but has no OpenBao policy. These contexts used the Developer role. This MR switches them to the Reporter role.

The Reporter role is correct for this purpose. The GitLab abilities to create, update, read, and delete project secrets start at the Reporter role. The Reporter role gets no default OpenBao policy.

A follow-up MR will add a default OpenBao grant to the Developer role. The grant gives the Developer role read access to metadata and the ability to create secrets, for projects. That work is the linked work item below.

After that follow-up MR merges, the Developer role no longer satisfies the condition "holds the ability, has no grant". The specs that still used the Developer role would then assert something false, and some would fail. The Reporter role keeps satisfying the condition, so the specs keep testing what they were written to test.

This MR makes the swap on its own. This keeps the follow-up MR's diff limited to the feature it adds.

The changed files are:

  • ee/spec/requests/api/graphql/secrets_management/project_secrets/access_control_spec.rb: two contexts switch from the Developer role to the Reporter role.
  • ee/spec/requests/api/graphql/secrets_management/project_secrets/create_spec.rb: one context switches.
  • ee/spec/requests/api/graphql/secrets_management/project_secrets/update_spec.rb: one context switches.
  • ee/spec/requests/api/graphql/secrets_management/project_secrets/list_needing_rotation_spec.rb: two contexts switch.
  • ee/spec/requests/api/graphql/secrets_management/project_secrets_managers/user_permissions_spec.rb: three changes.
    • This file already had a Reporter-role, no-grant context. Renaming the Developer-role context made it an exact duplicate. RuboCop rejects the duplicate through the RSpec/RepeatedExampleGroupBody and RSpec/RepeatedExampleGroupDescription cops. This MR deletes the duplicate block. The existing Reporter-role context gives the same coverage.
    • The "when current user has an expired grant" context switches to the Reporter role. It asserts that an expired grant leaves no capability. A Developer role default would mask that result.
    • The "when a leftover Group principal policy exists" context switches to the Reporter role, for the same reason.
  • ee/spec/support/shared_examples/services/secrets_management/provision_service_examples.rb: the shared example that asserts a role gets no default policy now names the Reporter role. Project provisioning will soon include the Developer role in its default roles, so the Developer role would no longer fit this assertion. The Reporter role never becomes a default role.

Some contexts keep the Developer role. These are contexts where the spec grants the user an explicit OpenBao permission, or grants the Developer role principal an explicit permission. This MR does not change these contexts, because the grant in them is explicit, not absent.

References

How to set up and validate locally

No manual or browser validation applies to this MR. This change is test-only.

To validate the specs locally:

  1. Start OpenBao. These specs talk to a real OpenBao instance.

  2. Run the request specs that changed:

    bundle exec rspec \
  ee/spec/requests/api/graphql/secrets_management/project_secrets/access_control_spec.rb \
  ee/spec/requests/api/graphql/secrets_management/project_secrets/create_spec.rb \
  ee/spec/requests/api/graphql/secrets_management/project_secrets/update_spec.rb \
  ee/spec/requests/api/graphql/secrets_management/project_secrets/list_needing_rotation_spec.rb \
  ee/spec/requests/api/graphql/secrets_management/project_secrets_managers/user_permissions_spec.rb

  3. Run the project secret service specs that changed:

    bundle exec rspec \
  ee/spec/services/secrets_management/project_secrets/create_service_spec.rb \
  ee/spec/services/secrets_management/project_secrets/delete_service_spec.rb \
  ee/spec/services/secrets_management/project_secrets/read_metadata_service_spec.rb \
  ee/spec/services/secrets_management/project_secrets/list_service_spec.rb \
  ee/spec/services/secrets_management/project_secrets/list_needing_rotation_service_spec.rb

  4. Run the specs that consume the two changed shared examples:

    bundle exec rspec \
  ee/spec/services/secrets_management/project_secrets_managers/provision_service_spec.rb \
  ee/spec/services/secrets_management/group_secrets_managers/provision_service_spec.rb \
  ee/spec/services/secrets_management/group_secrets/create_service_spec.rb

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.

🤖 Generated with Claude Code

Edited by Chaya Danzinger

Merge request reports