Secrets Manager: QA spec for non-CI API secret access (endpoint to OpenBao read)

Problem

Non-CI/CD secret access (#594090) is covered in-process by request specs tagged :gitlab_secrets_manager (which boot a real OpenBao server). That validates the mint-then-read path inside Rails, but not the real deployed network path an external client actually uses: a real token hitting the API, then the real external OpenBao URL.

Proposal

Add a QA spec for the non-CI API read path:

  1. Provision Secrets Manager on a project (and/or group).
  2. Create a secret.
  3. Call the new access-token endpoint via the API to get a JWT plus OpenBao connection details.
  4. Use the JWT to log into the real external OpenBao and read the secret.
  5. Assert the value matches.

This mirrors qa/qa/specs/features/ee/browser_ui/.../project_secret_ci_access_success_spec.rb (the pipeline read path) but for the API path. It reuses the existing SM QA scenario and helpers (qa/qa/ee/support/helpers/secrets_management/secrets_manager_helper.rb, qa/qa/scenario/test/integration/secrets_manager.rb).

Scope

  • In scope: the QA spec for the endpoint to OpenBao read flow. No ESO, no Kubernetes cluster.
  • Out of scope: a full ESO-in-a-cluster automated test. The QA framework has no ESO harness today, and the ESO flow is validated manually with design partners during 19.2 beta.

Related

  • #594090 (endpoint, this issue's parent)