doc/ci/secrets/secrets_manager/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
secrets_manager and ci_tanukey_ui. Disabled by default.ci_tanukey_ui removed in GitLab 18.4.group_secrets_manager.{{< /history >}}
Secrets represent sensitive information your CI/CD jobs need to function. Secrets could be access tokens, database credentials, private keys, or similar.
Unlike CI/CD variables, which are always available to jobs by default, secrets must be explicitly requested by a job.
Use GitLab Secrets Manager to securely store and manage secrets and credentials for your projects and groups.
GitLab Secrets Manager is free during public beta, but will consume GitLab credits when released as generally available. To avoid a service interruption, you will be notified before general availability to give you time to opt into on-demand billing for GitLab credits.
For a click-through demo, see GitLab Secrets Manager.
<!-- Demo published on 2026-05-27 -->Share your feedback during the public beta in feedback issue 598100.
When Secrets Manager is enabled for a top-level group, it is also available to all subgroups and projects in that group.
On GitLab Self-Managed, an administrator must first install and enable GitLab Secrets Manager for the instance. After Secrets Manager is installed and enabled, you can enable it for specific groups and projects on the instance.
Prerequisites:
To enable or disable GitLab Secrets Manager for a project:
In the top bar, select Search or go to and find your project.
In the left sidebar, select Settings > General.
Expand Visibility, project features, permissions.
Turn on the Secrets manager toggle and wait for the secrets manager to be provisioned.
[!warning] If you later disable the Secrets Manager for the project, all the project secrets are permanently deleted. These secrets cannot be recovered.
Secrets defined for a project can only be accessed by pipelines from the same project.
Prerequisites:
To enable or disable GitLab Secrets Manager for a group:
In the top bar, select Search or go to and find your group.
In the left sidebar, select Settings > General.
Expand Permissions and group features.
Turn on the Secrets manager toggle and wait for the secrets manager to be provisioned.
[!warning] If you later disable the Secrets Manager for the group, all the group secrets are permanently deleted. These secrets cannot be recovered.
Secrets defined for a group can only be accessed by pipelines in a project directly under the group or in its subgroup hierarchy.
You can add secrets to the secrets manager so that it can be used for secure CI/CD pipelines and workflows.
*)* character).After you create a secret, you can use it in the pipeline configuration or in job scripts.
[!warning] The value of a secret is accessible to all CI/CD pipeline jobs running for the specific environment or branch defined when the secret is created or updated. Ensure only users with permission to access the value of these secrets can run jobs for the specified environment or branch.
By default, similar to file type CI/CD variables, a secret is made available in a job as a file with an associated environment variable:
Use a secret in job scripts with commands that accept files as inputs, or optionally directly use the secret as an environment variable.
If a job outputs a secret's value, GitLab replaces the value in the job log with [MASKED].
Prerequisites:
To access secrets stored in the Secret Manager for a project, use the secrets
and gitlab_secrets_manager keywords.
For example:
job:
secrets:
KUBE_CA_PEM:
gitlab_secrets_manager:
name: kube-cert
script:
- kubectl config set-cluster e2e --server="https://example.com" --certificate-authority="$KUBE_CA_PEM"
Prerequisites:
To access secrets stored in the Secret Manager for a group:
secrets and gitlab_secrets_manager keywords.source field with the format group/<full-path-to-group>.For example:
job:
secrets:
KUBE_CA_PEM:
gitlab_secrets_manager:
name: kube-cert
source: group/my-group/my-subgroup
script:
- kubectl config set-cluster e2e --server="https://example.com" --certificate-authority="$KUBE_CA_PEM"
file: falseTo use a secret as an environment variable and not have it stored in a file,
set file: false for the secret. For example:
job:
secrets:
DEPLOY_SECRET:
gitlab_secrets_manager:
name: deploy-credentials
file: false
script:
- my_deploy_command --user username --pass $DEPLOY_SECRET
In this example, the secret is made available to the job as the DEPLOY_SECRET variable,
which you can use like any other environment variable.
Prerequisites:
To update the secrets permissions for a project:
Prerequisites:
To update the secrets permissions for a group:
Users with the Owner role for the group always have permissions to perform all operations in the Secrets Manager.
When you delete a project or delete a group with secrets:
When you transfer a project or transfer a group with secrets:
Users with the Owner role in the project receive an email notification to rotate a secret on the day specified in a secret's configuration.
reading from Vault: api error: status code 403When a CI/CD pipeline job attempts to fetch a secret, it might return this error:
ERROR: Job failed (system failure): resolving secrets: getting secret: get secret data: reading from Vault: api error: status code 403: 1 error occurred: * permission denied
This error happens when a job attempts to fetch a secret that does not exist or has been deleted.
inline auth JWT is requiredWhen a CI/CD pipeline job attempts to fetch a secret, it might return this error:
ERROR: Job failed (system failure): resolving secrets: creating vault client: configuring inline auth: inline auth JWT is required
This error happens when the secrets manager instance has not been provisioned yet for the project or the group that the secret is expected to belong to. The runner cannot configure authentication because no secrets manager role exists yet.
To resolve this error, enable the Secrets Manager for your project or group.
Wait for provisioning to complete and create the secret before re-running the pipeline.