@fcatteau yes, you are correct. Given we don't deprovision the group secrets manager, once they are moved to a new parent, this will now point to non-existent namespace: https://gitlab.com/gitlab-org/gitlab/-/blob/0295f47dd44b5b735b536f24e4b670a98fae1bc6/ee/app/models/secrets_management/group_secrets_manager.rb#L18-22
Add a note in the GitLab Secrets Manager documentation explaining that secrets are injected as temporary files, similar to the HashiCorp Vault integration.
This clarifies that the CI/CD variable contains the path to the temporary file, not the secret value itself, and documents the optional file: false parameter to change this behavior.
doc/ci/secrets/secrets_manager/_index.md to include:
file: false to get the secret value directly!226133 (merged) is now merged so we can close this now.
cc @fcatteau
This guard is not needed. Our query excludes owners that are blocked or inactive. I also improved the specs to test this behavior specifically.
Erick Bajao (c85c8b35) at 16 Mar 17:17
Address undercoverage
@fcatteau @jmallissery I realize we need to update this MR to also do this for the new pipeline CEL auth.
Correlate pipeline, job identifiers in audit logs
When pipelines execute against GitLab Secrets Manager, we should pass through the pipeline/job identifier in the OpenBao audit logs. This requires adding the information to the token metadata.
This change does not affect existing projects as we're still in closed experiment. Existing projects can pick up the new behavior by disabling and re-enabling on the project/group level.
Issue: #593674
See also: https://gitlab.com/gitlab-org/gitlab/-/issues/577901+
TBD
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.