Credentials often start in an engineer's local dev environments, then get copied into unscoped CI/CD variables to keep pipelines running. Stored there as a raw value rather than a reference to a scoped secret, a signing key reaches every job in the pipeline — compromised or not.

Standing up a standalone vault narrows that exposure but requires mirroring every change to project membership, protected branches, and production environments. When the vault falls out of sync, a pipeline breaks or an agent’s service account keeps access it no longer needs.

GitLab Secrets Manager tightens credential security without a second permission model. It is now generally available in GitLab 19.5 for Premium and Ultimate on GitLab.com and GitLab Self-Managed, with GitLab Dedicated coming soon. Built on OpenBao, it stores build-time and runtime credentials under the same permissions and audit trail as your code. Platform teams can offer developers self-service secrets, and security teams get credentials scoped to the jobs that use them, plus the pipeline and job ID on every CI/CD read.

"GitLab Secrets Manager lets us centralize secrets across CI/CD, Kubernetes, and infrastructure as code without standing up multiple vaults or maintaining separate integration points. It also strengthens our supply chain security by tightening which users and pipelines can access a given credential." - Jeremy Nauta, Software Architect, OneTrust

How Secrets Manager scopes build-time secrets to each job

Agents can take actions no one anticipated, so security teams need to regard every job as if its agents will use any credential it can reach. Secrets Manager narrows what agents can reach with the context GitLab already holds about each job: its project, the branch it runs on, whether that branch is protected, and the environment it targets.

A developer declares the secret a job needs with the secrets: keyword in .gitlab-ci.yml, and GitLab injects the value only into jobs that declare it and fall within its scope. Scope conditions accept wildcards on branch and environment, and they combine, so one rule can require a protected branch and a production/* environment before a job receives the credential.

Inside the job, GitLab writes the value to a temporary file and exposes only its path, which limits exposure in subprocesses, crash dumps, and telemetry. GitLab masks the value in job logs and discards it when the job ends. Unlike a CI/CD variable, a secret is never readable in your project configuration. OpenBao encrypts secrets at rest with AES-256-GCM, so a copy of the secrets database holds only ciphertext. Jobs fetch values straight from OpenBao with short-lived tokens bound to each job’s identity, which keeps plaintext secrets out of the GitLab application.

See how to get started with Secrets Manager:

Revoke and trace an exposed credential

When the axios npm package was compromised, a SANS advisory warned teams to "assume all environment variables on affected systems were exfiltrated" and extend investigations to CI/CD runners and build infrastructure. Responders had to work out which credentials each affected job could read, how to cut off access, and which runs read them.

With Secrets Manager, when a job runs a poisoned dependency, the exposure stops at the secrets that job declared and was authorized to read. To clean up, revoke and replace the leaked credential, update the value in Secrets Manager, and audit that one job while other pipelines keep running. Secrets Manager prompts you to set a rotation reminder when you create a secret. Dynamic credentials are coming soon and will provide ephemeral access without manual rotation.

GitLab streams every secret create, read, update, and delete event to your audit event destinations and records changes in the audit trail. Each pipeline read carries the pipeline and job IDs, which tie to the commit, the triggering user, and the merge request, when there is one. Incident responders and auditors can trace a read to the change behind it without correlating logs from a CI system, a vault, and an identity provider. Audit events never contain secret values.

Govern secrets with the permissions that govern your code

As agents take on more work, platform teams field more requests for pipelines and service accounts that need credentials. When those requests queue, teams fall back on broad grants and shared secrets.

Secrets Manager uses the GitLab namespace as its isolation boundary. Projects inherit secrets defined in the groups above them, so you define a shared credential once. Owners grant read, write, and delete permissions to specific users or default roles, using the same membership model that governs the code. Remove a person or an agent's service account from a project, and that identity's access to the project's secrets ends.

Developers reference secrets through the project access they already hold. When a secret reference breaks, they fix it in the same merge request as the code, with no second repository, approver, or access ticket. With a governed credential one line away, fewer secrets end up in over-scoped CI/CD variables, local files, or the repository.

One store for pipelines and runtime workloads

Kubernetes, Terraform, and scripts often get separate secret stores, each with its own access model and logs. Secrets Manager serves runtime tools from the same store as pipelines, under the same permissions and audit trail:

  • Kubernetes, through External Secrets Operator. ESO re-fetches the secret on a set interval and updates the Kubernetes Secret in place, so a rotated value reaches the cluster without a pipeline run.
  • Terraform and OpenTofu. They read a secret as a data source at plan or apply time and keep credentials out of .tfvars files and CI/CD variables.
  • OpenBao and Vault CLIs, through the Vault-compatible API. Teams keep their existing scripts and point them at Secrets Manager.
  • Other runtime tools, through the Secrets Manager API.

Each runtime tool authenticates with a service account or an access token, and that identity needs project membership and explicit read permission for the secret. GitLab then issues a separate token, valid for five minutes, that the tool uses to fetch it.

How Secrets Manager fits with GitLab's supply chain controls

GitLab’s governed software factory connects code, pipelines, packages, and secrets on one platform, with one identity model and one record of how a change reached production. Dependency Firewall decides which packages enter a pipeline, Secrets Manager limits which credentials the pipeline can reach, and Artifact Central governs what you ship.

Secrets Manager supports two of the five stages in the GitLab Security Standard, GitLab's framework for letting agents earn autonomy: For Authorize, it binds each job to the secrets its identity and scope allow, and for Respond, it streams every CRUD event.

Secret push protection blocks commits containing credentials before they reach the repository, and Secret detection finds the ones already in your code and history. GitLab Duo Agent Platform triages what those scans find and flags likely false positives, so your team revokes, rotates, and audits only real leaks.

GitLab's existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager keep working alongside Secrets Manager, so you can migrate at your own pace.

Get started

GitLab Secrets Manager is a paid add-on for Premium and Ultimate, billed through GitLab Credits: 1 credit per secret stored per month, and 1 credit per 2,500 read operations. An enterprise license agreement is available for air-gapped environments.

  • On GitLab.com, top-level group Owners can try GitLab Secrets Manager free for 30 days or 500 evaluation credits, whichever ends first. Go to your top-level group, select Secure > Secrets Manager, then Start 30-day trial.
  • On GitLab Self-Managed, your administrator must install and enable Secrets Manager, following the documented sizing and high-availability guidance.
  • GitLab Dedicated support is coming soon.

To find the first credentials to move, run the secret audit tool for CI/CD variables, which flags variables likely to hold credentials. A migration workflow for CI/CD variables is in development.

Have suggestions or feedback? Share them in the Secrets Manager feedback issue.