One store instead of many
Many teams still keep separate secret stores for CI/CD pipelines, Kubernetes workloads and Terraform. That creates multiple tools to manage, access models to keep in sync, and audit trails that are hard to correlate when something goes wrong.
GitLab Secrets Manager, powered by OpenBao, now supports External Secrets Operator (ESO) and Terraform. The same secret store can serve CI jobs, cluster workloads and infrastructure-as-code without copying credentials into multiple places.
External Secrets Operator integration
ESO syncs secrets from GitLab Secrets Manager using the Vault provider. A workload holds a short-lived JWT that ESO uses to authenticate with OpenBao; the secret is then written into a native Kubernetes Secret.
A SecretStore resource tells ESO where to fetch secrets and how to authenticate. GitLab exposes a Vault-compatible KV v2 API. The namespace field maps to the GitLab hierarchy (organization, group, project) and scopes which secrets the store can reach. Authentication uses a GitLab-minted JWT stored in a Kubernetes secret and referenced by secretRef.
An ExternalSecret resource defines which secrets to pull and where to place them. It references the SecretStore, maps remote paths to keys in a target Kubernetes secret, and re-fetches on a configurable refreshInterval so rotated values appear without a redeploy.
Terraform and CLI access
Terraform state and variable files are a common source of leaked credentials. Terraform can now read a GitLab secret as a data source, authenticating with a minted JWT at plan or apply time. Credentials never need to be written to disk or checked into version control.
Teams that already script against Vault-compatible tooling can use the OpenBao or Vault CLI against GitLab Secrets Manager exactly as they would against Vault. For automation that does not fit CI, Kubernetes or Terraform, the API lets any external system fetch secrets instead of hard-coding credentials or maintaining separate variable files.
Availability and pricing
The new integrations are available for Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. GitLab Dedicated support is coming soon. Secrets Manager remains free during the beta period. When it reaches general availability it will become a paid feature billed through GitLab’s existing model; customers will need to opt in before any charges begin and will receive advance notice.
The practical outcome is a single source of truth for secrets across the delivery chain, with native paths into the three places most teams already operate.