Enable secrets manager on a project (Backend)
This is the main entry point for project owners to activate secrets manager on their project. All other feature work for the secrets manager will rely on this being implemented first.
This is for the backend implementation. The frontend work is tracked in #469581 (closed).
This is based off of the design wherein there's a toggle to activate the secrets manager on a project:

What needs to be done
-
MR 1: OpenBao AppRole role and policies for enabling a secret engine should be predefined.
- For now, we can just focus on making this work for GDK. We can have a rake task similar to https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/09f185586189cbd34e1590dc55a8377963b2aedc/lib/tasks/vault.rake that we will use to seed GDK's OpenBao will all the needed roles and policies.
-
MR 2: GraphQL mutation to activate secrets manager on a project.
- Ensure proper permissions are enforced based on the user role.
- Utilize Vault's ruby client library.
- Enable the secret engine mount for the project, similar to what was done in #467150 (comment 1960228236).
- We need to use AppRole instead of JWT authentication with OpenBao.
- ActiveRecord model to track the secret engine path of the project when activated. Maybe something like
SecretsManager::ProjectConfig?
Edited by Erick Bajao