Add Runner Integration for Group Secrets
Why this MR?
- As a part of gitlab Native Secrets Manger, we are implementing Group level secrets
- This MR is to enable CI pipeline jobs to specify in
ci.yamla CI secret defined at any of the parent groups of the project - This MR also adds the logic in Rails to generate and forward the ID token payload needed for the runner to fetch the secret specified above from Openbao(our secrets engine)
What does this MR do?
- Update the CI config parsing logic to add source group for secrets
- The way a user can specify a secret from a group as follows
job:
secrets:
TEST_SECRET:
gitlab_secrets_manager:
name: foo
source: group/<path_of_the_group>
script:
- cat $TEST_SECRET
- Update Rails payload to runner for CI jobs to fetch secrets from it's groups
Screenshots
| CI yaml | Ci job execution logs |
|---|---|
|
|
How to test locally
- Pull down this change locally.
- Create a group secret via Rails console
user = User.find_by(username: 'your_username')
group = Group.find_by(path: 'your_group_path')
Labkit::Correlation::CorrelationId.use_id(test_correlation_id) do
result = SecretsManagement::GroupSecrets::CreateService.new(group, user).execute(
name: 'TEST_AUDIT_SECRET',
value: 'test_secret_value',
environment: '*',
protected: false,
description: 'Test secret for audit log verification'
)
puts "Create result: #{result.success? ? 'SUCCESS' : result.message}"
end
- Run a CI job with YAML file structure mentioned above
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 Jayakrishnan Mallissery

