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.

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.

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.

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.

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.

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.

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.

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.