gitlabAug 6, 2026

GitLab Secrets Manager adds ESO, Terraform, API support (opens in new tab)

GitLab Secrets Manager expands beyond CI/CD by supporting Kubernetes, Terraform/OpenTofu, CLI tools, and external automation. Built on OpenBao and compatible with Vault APIs, it provides one centrally managed secret store with consistent access controls and auditing. The result is fewer duplicated credential stores and safer secret retrieval across the software delivery lifecycle. ## Kubernetes with External Secrets Operator - ESO uses its Vault provider to retrieve secrets from GitLab Secrets Manager. - A Kubernetes workload uses a short-lived GitLab-minted JWT to authenticate with OpenBao. - A `SecretStore` configures: - The Vault-compatible server and KV v2 mount - The GitLab organization, group, and project namespace - JWT authentication and the Kubernetes secret containing the token - An `ExternalSecret` maps remote secrets to a Kubernetes `Secret`. - ESO refreshes values according to `refreshInterval`, allowing rotated credentials to reach workloads without redeployment. - `remoteRef.key`, `property`, and `secretKey` define the source path, field, and destination key. ## Terraform and OpenTofu Integration - Terraform can retrieve secrets at plan or apply time instead of storing them in `.tfvars` files or CI/CD variables. - A script obtains a minted JWT and connection metadata through Terraform’s `external` data source. - The Vault provider uses that JWT to authenticate against GitLab Secrets Manager. - The `vault_kv_secret_v2` data source reads the required secret. - Outputs containing secrets should be marked `sensitive`, though downstream Terraform state handling still requires care. ## OpenBao and Vault CLI - Existing Vault-compatible scripts can access GitLab Secrets Manager without using the API directly. - Users configure `VAULT_ADDR` and `VAULT_NAMESPACE`. - A minted JWT is exchanged for an OpenBao client token through the configured JWT authentication path. - The `vault kv get` command then retrieves secrets from the KV mount. ## Secrets Manager API - The API supports automation outside GitLab CI/CD, Kubernetes, and Terraform. - A service account requests an access token through GitLab’s project API. - The response supplies the Vault server, namespace, mount, secrets path, JWT authentication path, and role. - External systems can use this information to authenticate and fetch secrets without hardcoded credentials or separate variable files. GitLab Secrets Manager is most useful when multiple deployment tools need the same credentials. Centralizing secrets in the OpenBao-backed store, using short-lived JWT authentication, and integrating through ESO, Terraform, CLI, or the API can reduce duplication and improve rotation and auditing.

gitlab-secrets-managerk8sterraformjwt+4

gitlabMay 21, 2026

Manage CI/CD credentials with GitLab Secrets Manager (opens in new tab)

GitLab Secrets Manager, entering public beta with GitLab 19.0, provides a native way to manage CI/CD credentials without storing them in broadly scoped variables or configuration files. Built on OpenBao and integrated with GitLab’s existing permissions, environments, branches, and audit trails, it aims to reduce credential exposure and simplify incident response. The post recommends trying it in existing GitLab projects and pipelines, especially where least-privilege access is difficult to enforce. ## Where CI/CD Secrets Commonly Go Wrong - Developers often store credentials in: - Project- or group-level CI/CD variables - Configuration files - Accidentally committed `.env` files - Masked CI/CD variables may still be exposed to every job and anyone with pipeline access. - Standalone vaults improve separation but introduce: - A second authentication system - Separate permission models - Additional audit logs and operational overhead ## Using GitLab Secrets Manager - Secrets are stored within GitLab’s existing project and group structure. - Pipelines reference secrets with the `secrets:` keyword in `.gitlab-ci.yml`. - By default, GitLab writes the secret to a temporary file and exposes its path to the job. - Passing a file path instead of the raw value can reduce exposure in: - Subprocesses - Crash dumps - Telemetry systems ## GitLab-Based Access Controls - Secrets use GitLab’s existing users, groups, projects, and roles. - Permissions can be assigned for reading, creating, updating, and deleting secrets. - Group-level secrets are inherited by nested projects, allowing common credentials to be defined once. - Removing someone from a project or group immediately removes their access to its secrets. - This avoids maintaining a separate access hierarchy that could drift from GitLab’s permissions. ## Job-Level Secret Scoping - Each secret can be restricted based on: - Target environment - Branch - Whether the branch is protected - Wildcards such as `production/*` simplify environment and branch rules. - Multiple conditions can be combined, such as requiring both a protected branch and a production environment. - At runtime, the backend verifies the job’s identity and scope before returning the secret. - Secrets are discarded when the job ends, and job logs are masked. - Narrow scopes reduce the systems affected if a dependency or pipeline is compromised. ## Auditing Secret Usage - Secret creation, updates, and deletions appear in GitLab’s existing audit trail. - Pipeline secret reads include the originating pipeline and job IDs. - Responders can trace where a credential was used without correlating separate systems manually. - Audit logging is available for self-managed deployments; GitLab.com support is expected during the beta. ## Public Beta Availability - The beta is available to Premium and Ultimate users on GitLab.com and self-managed deployments. - GitLab Dedicated support is planned. - The feature is free during beta and will later become a paid GitLab Credits feature. - Existing integrations with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager remain available. GitLab Secrets Manager is best suited for teams that want least-privilege CI/CD credentials while keeping access control and auditing within GitLab. Teams can adopt it incrementally alongside existing external secrets platforms.

gitlab-secrets-managerci-cdaccess-controlsecrets-management+3