What Is GitLab Secrets Manager?
GitLab Secrets Manager, now in public beta with GitLab 19.0, keeps credentials inside the same platform that runs your code and pipelines. It’s built on OpenBao and is a native GitLab capability, not a third-party integration you have to stand up separately.
The access model uses your existing group and project structure. Secrets created at the group level are inherited by every project nested beneath it. When someone is removed from a project, they immediately lose access to its secrets. There’s no second permission model to build, maintain, or reconcile.
Each secret is scoped to the jobs that actually need it, based on three attributes GitLab already tracks: the environment the job targets, the branch it runs on, and whether that branch is protected. When a job runs, it requests the secret, the backend verifies the job’s identity against the scope rules, and the value is written to a temporary file for that job only. When the job ends, the secret is discarded. Nothing persists to the runner, and job logs are masked. A CI variable, by contrast, stays readable in your project config indefinitely.
Audit logging captures create, update, and delete events alongside the rest of your governance record. Secret reads from pipelines stream as audit events with the originating pipeline and job IDs attached, so security teams can trace exactly where a credential was used without manually pulling logs from multiple systems.
GitLab Secrets availability and pricing
Secrets Manager is in public beta for Premium and Ultimate users on both GitLab.com and self-managed deployments. It’s free during the beta period. Once generally available, it will be a paid feature billed through GitLab Credits, and you’ll need to opt in before anything is charged.
Existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager continue to work alongside it, so there’s no forced migration.
What are secrets in DevSecOps?
Every application that talks to another system needs a way to prove it’s allowed to. The credentials it uses to do that, whether they are database passwords, API keys, cloud provider tokens, or private certificates, are called secrets. They’re called that for a reason: if the wrong person or system gets hold of one, they can access whatever that credential was authorized to reach.
Managing secrets sounds simple until you’re doing it at scale. Secrets need to reach the pipelines that build and deploy your software, which means they have to live somewhere accessible, this is the problem that GitLab Secrets solves.
Where secrets usually end up
The default for most teams is CI/CD variables. Set the variable at the project level, mask the value, and move on. It works, but it inverts the principle of least privilege in that the secret is readable by anyone with pipeline access and injected into every job, whether that job needs it or not. The blast radius of a single leaked credential is as wide as your pipeline.
The usual alternative is a standalone vault. That gets secrets out of your CI/CD config, but it creates a permanent operational tax in a separate system to authenticate, a separate access model to maintain, and a separate audit log to correlate when something goes wrong.
If you want help thinking through how you manage secrets in your existing GitLab environment, reach out to us. We work with GitLab customers across commercial and federal environments and can help you evaluate what the right secrets management setup looks like for your organization.