GitLab Secrets Manager reaches beyond CI jobs to ESO, Terraform, and an API

Every secret in your pipeline is a stranger with root. You typed it into a vault six months ago, wired it into three tools, and now you get to explain to audit why the Kubernetes cluster and the Terraform run and the smoke test each pull it from a different place with a different lifetime. On August 6, GitLab tried to shrink that pile. GitLab Secrets Manager, in public beta, now speaks to the External Secrets Operator, to Terraform and OpenTofu, and to anything that can hit a Vault-compatible API.

Behind the curtain it is OpenBao, the community fork of HashiCorp Vault, so the surface a client sees is a Vault-compatible KV v2 API. Short-lived JWTs do the auth. Familiar shape, GitLab holding the keys.

The trust boundary that actually moved

Since Version 19.0 you have been able to pull a secret straight into a CI/CD job from Secrets Manager. Useful, and narrow. The three new consumers widen the coverage without spawning a second secrets store to keep in sync.

• ESO now has a working Vault-provider path against Secrets Manager. Your SecretStore authenticates with a short-lived JWT, the operator writes a Secret into the target namespace, and the workload reads it the way it always did. No more offline copy of the same value baked into a sealed secret.
• Terraform and OpenTofu can read secrets as data sources during plan and apply, so .tfvars files stop being the graveyard where credentials go to rot, and state files stop checkpointing values they were never meant to hold.
• The API finally opens the platform up to whatever weird script or non-CI job you have inherited: a Lambda, a cron on a jump host, a bespoke migration tool. Point OpenBao CLI or the Vault CLI at it directly.

None of that is a moon shot on its own. Each is table stakes for a secrets platform that wants to be called one. What is interesting is that all three now live in the same URL your .gitlab-ci.yml already talks to, with the same audit trail and the same access model. Fewer copies of the same value in flight is a real, measurable trust win.

Where is the catch?

Two, and one is honest, one is billing.

The honest catch: this is public beta, and only Premium and Ultimate customers see it. GitLab.com and Self-Managed are in; Dedicated is coming later. A beta secrets store is a fine place for a proof-of-concept, and a bad place for the credential that owns your production database. Read the SLO, or its absence, before you migrate.

The billing catch: free during beta, then billed through GitLab Credits at general availability, with an explicit opt-in required before any charges land. Read that as: GA will be a decision point, not a background upgrade. Budget for it or plan the exit path now, while the volume is small.

How other tools handle CI/CD secrets

You have options, and honestly some of them are further along:

• HashiCorp Vault is still the reference: the broadest set of auth methods, dynamic secrets on the AWS, GCP and database engines, and the deepest ecosystem of tutorials for the mistakes you are about to make. If your fleet is polyglot and you already run Vault, GitLab's version is a convenience, not a reason to migrate.
• OpenBao is the same core, community-owned. If licensing was the reason you were shopping in the first place, run it yourself. GitLab is essentially selling you managed OpenBao.
• AWS Secrets Manager, Google Secret Manager, Azure Key Vault are the pragmatic pick if your workloads live mostly in one cloud. IAM and workload-identity flows are boring in a good way, and rotation for RDS, Cloud SQL and friends is already wired.
• Doppler and 1Password Secrets Automation compete on developer experience: sync targets across environments and a UI the ops-curious colleagues will not fight.
• Buddy keeps secrets scoped per pipeline and per environment inside the CI platform itself, and can pull from AWS Secrets Manager, Vault or Doppler as upstream sources. Concrete reason to consider it: if your CI already runs on Buddy, keeping the secret plumbing in the same tool means one fewer identity provider to reason about at 3am. It is not the pick for a multi-runner enterprise estate, though. Vault or a cloud-native manager wins there on breadth of engines and rotation coverage.

Verdict

Coalescing secret plumbing onto whatever platform runs your CI is a defensible instinct: one identity provider, one audit stream, one thing to page on when the auth path breaks. GitLab is now close enough to that story to be worth a beta trial for teams already committed to the platform. Everyone else: keep your Vault, watch this land at GA, revisit when the billing shape is public and Dedicated has caught up.

One secret store. Fewer footguns. Same old rotation problem, though.