SECRETS MANAGER

Native secrets management on the platform your teams already use

End secret sprawl with GitLab Secrets Manager, built on OpenBao. Pipeline and runtime secrets read from one store, governed by the permissions and audit trail that already cover your code.

Manage secrets where developers already work

With GitLab Secrets Manager, secrets live in the same groups and projects as the code that uses them, so requesting one fits the normal workflow with no plugin, agent, or second tool to learn.

A merge request changing a secret name in the pipeline configuration file, reviewed and approved alongside the code.

Governed like your code

Access follows your existing group and project hierarchy and fine-grained permissions offer extra control, so there isn't a second access model to keep in sync. Define a credential once at the project level or shared across the group. Anyone who leaves a project loses access automatically.

Declared in the pipeline config

A developer declares the secret a job needs with the secrets: keyword in the pipeline configuration file. GitLab already knows the job's project, branch, and environment, so there is no identity to wire up between CI and a separate vault.

Fixed in one merge request

When a secret reference breaks, the fix ships in the same merge request as the code, with no second repo or approver. With secure credentials one line away, fewer secrets end up in CI variables, local config files, or the repo.

Limit the blast radius of exposed credentials

When a compromised dependency runs inside a job, cleanup with GitLab Secrets Manager means rotating and auditing the secrets that job could reach, not freezing every pipeline.

A job requesting a secret, the scope matching on branch and environment, and the secret being injected into the job.

Scoped to the job

Unlike CI variables, which reach every job in the pipeline, a secret reaches only the jobs that declare it and fall within its scope: branch, environment, and protection status.

Discarded when the job ends

Secrets Manager writes the value to a temporary file and exposes only its path, limiting exposure in subprocesses, crash dumps, and telemetry. The value is masked in job logs and discarded when the job ends, so nothing persists on the runner.

Traced from read to deployment

Create, read, update, and delete events land in the same audit trail as the rest of GitLab. Pipeline reads carry pipeline and job IDs, so responders and auditors trace a credential from access to deployment without correlating logs across systems by hand.

One store for pipelines, clusters, and infrastructure

Pipelines read secrets directly. Kubernetes workloads, Terraform and OpenTofu runs, Vault-compatible CLI tools, and other automation connect through standard integration points, under the same permissions and audit trail as pipelines.

GitLab CI/CD pipelines, Kubernetes, Terraform, OpenTofu, and other automation all reading from a single GitLab Secrets Manager store.

Served to Kubernetes, Terraform, and OpenTofu

External Secrets Operator keeps Kubernetes secrets in sync with GitLab, so rotated values propagate without a redeploy. Terraform and OpenTofu read secrets as a data source when they run, keeping credentials out of files and CI/CD variables.

Fetched by Vault-compatible clients and API

Built on OpenBao, Secrets Manager exposes a Vault-compatible API, so teams already scripting against the OpenBao or Vault CLI keep the commands they have. Any other automation fetches secrets through the Secrets Manager API instead of hardcoding credentials or maintaining separate variable files.

Kept in one store as targets change

Credentials follow multi-cloud, hybrid, and on-premises workloads without per-platform identity federation. Moving a workload to another cloud doesn't mean standing up a second store, and secrets otherwise scattered across per-account and per-region stores live in one place.

[ PROTECTION ]

Block and detect secret leaks

GitLab goes beyond managing credentials. Secret push protection blocks credentials from reaching the repository, client-side detection catches secrets in issue and merge request text, and pipeline secret detection finds secrets already in code. Duo Agent Platform triages the findings and flags likely false positives.

Explore secret detection
A GitLab Secret Detection finding showing the scanner, affected file, and validity check for a detected secret.

[ PRICING ]

Only pay for what you use

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 secret read operations. If you prefer a flat fee, an enterprise license agreement ELA is available.

Learn more about billing
An abstract graphic of a single stored secret being read by several consumers, metered through GitLab Credits.

// OWN WHAT’S NEXT

Get started with GitLab Secrets Manager

Already a Premium or Ultimate customer? Top-level group Owners can trial GitLab Secrets Manager at no cost for 30 days or 500 evaluation credits, whichever ends first.

Start your trial

Is your security modernization
delivering at scale?

GitLab built this maturity framework from its work with industry-leading customers. Answer a few questions about how your team handles security and compliance to get your maturity score and recommendations for the next stage.

Get your security maturity score

Quiz takes 5 minutes or less

Frequently asked questions