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.