TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

GitLab Secrets Manager

17 posts · Mar 2018 – Aug 2026

What this trail covers

GitLab is developing a native secrets manager to simplify secret management across the DevSecOps platform. The initial release will focus on CI workflows, with plans to expand to all GitLab workflows. It will support an open-source secrets manager (OpenBao) and integrate with existing security capabilities like secret detection, access token management, compliance audit logging, and secured artifacts. The goal is to reduce complexity, lower risk, and provide a centralized, cloud-agnostic solution, while continuing to support third-party integrations.

All GitLab trails
  1. GitLab Secrets Manager adds ESO, Terraform, API supportThis post details the integration of GitLab Secrets Manager with External Secrets Operator (ESO) for Kubernetes, enabling secrets to be synced from GitLab to Kubernetes Secrets using a Vault provider and JWT authentication. It also describes how Terraform/OpenTofu can read secrets directly from GitLab Secrets Manager using a Vault provider and minted JWTs, avoiding storage in `.tfvars` or CI/CD variables. Additionally, it covers using the OpenBao/Vault CLI and the Secrets Manager API for external automation.
  2. Manage CI/CD credentials with GitLab Secrets ManagerIntroduces GitLab Secrets Manager, a new capability built on OpenBao, for managing CI/CD credentials. It allows secrets to be scoped to specific jobs based on environment, branch, and protection status, reducing the blast radius of leaks. Secrets are declared in `.gitlab-ci.yml` using the `secrets:` keyword and are passed to jobs via temporary files. Access control is managed through existing GitLab group and project permissions. Audit logs for secret management and reads are now available.
  3. A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.Introduces fine-grained Personal Access Tokens (PATs) as a beta feature. These tokens allow for precise scoping of permissions to specific projects or groups and granular control over resource-level actions (Create, Read, Update, Delete) for various entities like Issues, Merge Requests, Pipelines, Repositories, and Container Registry. This contrasts with traditional PATs which have broad scopes. The feature aims to minimize the blast radius of leaked tokens. The tokens table has been updated for auditability. Future roadmap includes support for remaining REST API endpoints and GraphQL coverage.
  4. Solving complex challenges with GitLab Duo WorkflowThis post details the implementation of a dynamic Helm chart limit configuration for the GitLab package registry. The contribution involves adding a new key to the `package_registry` jsonb column in application settings to store the Helm chart limit. It also describes the creation of a new section in the Admin UI for administrators to set this limit and the modification of the backend logic in `app/finders/packages/helm/packages_finder.rb` to use this new application setting instead of the hardcoded limit. This enhancement was successfully merged and made available in GitLab 17.10.
  5. How to scan a full commit history to detect sensitive secretsIntroduces the `SECRET_DETECTION_HISTORIC_SCAN` variable for GitLab Secret Detection, enabling scans of the full commit history across all branches. This addresses the risk of secrets remaining in deleted files or old branches. The post details how to enable this feature via `.gitlab-ci.yml` and showcases example results, including a password in a deleted file and an AWS Access Token in a feature branch. It also reiterates existing secret detection features like push protection, pipeline scanning, client-side detection, and automatic response to leaked secrets.
  7. Best practices to keep secrets out of GitLab repositoriesThis post reinforces best practices for preventing secrets from being exposed in GitLab repositories. It highlights the importance of limiting public visibility of projects, securing CI secrets using external secret managers (GCP Secret Manager, AWS KMS, HashiCorp Vault), and enabling GitLab's comprehensive secret detection capabilities: secret push protection, pipeline secret detection, and client-side secret detection. It also provides guidance on incident response for accidental credential leaks, including resetting credentials and reviewing logs.
  8. Prevent secret leaks in source code with GitLab Secret Push ProtectionIntroduced Secret Push Protection, a feature that blocks secrets from being pushed to GitLab by checking commit content for high-confidence secrets. This feature is generally available for Ultimate and Dedicated customers. Added support for skipping push protection via Git options or commit messages. Introduced exclusions for paths, rules, or raw values. Added audit events for enabling/disabling the feature, skipping pushes, and managing exclusions.
  9. GitLab native secrets manager boosts supply chain securityThis post announces the upcoming native GitLab Secrets Manager, detailing its planned features and integrations. It highlights the current reliance on third-party solutions and the motivation for a native offering. Key planned integrations include automatic placement of detected secrets and access tokens into the manager, integration with audit logging for compliance, and securing credentials for verifiable artifact attestation. The post also mentions the use of an open-source secrets manager (OpenBao) and the intention to support multiple secret management solutions.
  10. How Secret Detection can proactively revoke leaked credentialsThis post details an expansion of GitLab Secret Detection's automatic response capabilities, specifically integrating with Google Cloud to automatically revoke leaked Google Cloud service account keys, API keys, and OAuth client secrets found in public projects on GitLab.com. This integration is available for GitLab Ultimate users and is enabled by default for projects using Secret Detection. It builds upon existing automatic response features for GitLab Personal Access Tokens and extends protection to any public branch.
  11. Secure GitLab CI/CD workflows using OIDC JWT on a DevSecOps platformThis post introduces the evolution of JWT support in GitLab CI/CD, moving from initial JWT (V1) for Hashicorp Vault integration to OIDC JWT (V2) for broader cloud provider integration, and finally to a production-ready OIDC token. It details the opt-in mechanism for JWT token usage to minimize exposure and the importance of the audience claim for security. The post also announces breaking changes and backward compatibility plans leading up to GitLab 16.0, where only the secured OIDC token will be available. It provides guidance on configuring pipelines to use the `id_token` keyword and enabling the 'Limit JSON Web Token (JWT) access' setting.
  12. Mobile DevOps: iOS code signing with GitLab CI & FastlaneThis post details the integration of GitLab's Project-level Secure Files with Fastlane Match for iOS code signing. It explains how to set up Fastlane Match to use GitLab Secure Files as a storage backend, generate Personal Access Tokens for local machine usage, and use Fastlane Match to generate and upload signing certificates and provisioning profiles to GitLab. It also provides examples of how to use these secure files within CI/CD pipelines for building iOS applications, including a sample Fastfile and .gitlab-ci.yml configuration.
  13. Mobile DevOps with GitLab, Part 2 - Code signing for Android with GitLabThis post details the technical steps for generating an Android Keystore file using `keytool`, configuring `app/build.gradle` to use environment variables for signing configurations, and setting up CI variables in GitLab. It also provides a sample `.gitlab-ci.yml` file that uses the `glab` CLI to download secure files and execute the Android build process.
  14. Mobile DevOps: Code signing with project-level secure filesIntroduced Project-level Secure Files as a new feature in GitLab 15.0, allowing users to upload and store sensitive binary files (e.g., keystores, signing certificates, provisioning profiles) directly within a GitLab project but outside of version control. Detailed the process of uploading these files via the UI and demonstrated how to download them within a CI/CD job using the `glab CLI` tool, enabling their use in mobile code signing workflows.
  15. GitOps with GitLab: How to tackle secrets managementThis post details the setup and usage of Bitnami's Sealed Secrets for managing Kubernetes secrets within a GitOps workflow. It covers installing the Sealed Secrets controller, retrieving the public key for encryption, and using the `kubeseal` CLI tool to encrypt native Kubernetes Secrets into `SealedSecret` custom resources. It also provides a utility script for simplifying the sealing process and discusses the benefits of Git-based secrets management, such as versioning and collaboration via merge requests.
  16. How to secure your software build pipeline using code signingThis post details a partnership between Venafi and GitLab to enhance software build pipeline security through code signing. It explains the importance of signing artifacts early and often to prevent supply chain attacks, the challenges of managing PKI and keys, and how the Venafi CodeSign Protect solution integrates with GitLab to simplify the code signing process for developers. The post also highlights the 'shift-left' security approach and provides resources for further learning.
  17. Package Hunter: Detect malicious code in dependenciesIntroduced Package Hunter, a new tool for detecting malicious code in program dependencies. Package Hunter installs dependencies in a sandbox and monitors system calls using Falco. It supports NodeJS modules and Ruby Gems and integrates with GitLab CI.
  18. How we’ll simplify Vault access for GitLab CI/CD usersThis post details an MVC approach to integrate HashiCorp Vault with GitLab CI/CD. The proposed solution involves instructing GitLab Runner, via Rails, to fetch secrets from Vault. This simplifies access to stored variables by leveraging Vault as a dedicated secrets store and implementing rotation and access control for enhanced security. The approach prioritizes a simpler runner-based solution over a more complex Rails integration with Vault.
  19. Introducing Token-HunterThis post introduces Token-Hunter, a new tool developed by GitLab's Red Team to identify unintentionally leaked secrets (API tokens, usernames, passwords) in public GitLab assets such as issues, snippets, merge requests, and their discussions. It complements existing tools by focusing on these less-indexed public locales. The tool features proxying capabilities and employs request retries and dynamic page-size reduction for data gathering. Future plans include support for more asset types and improved output formatting.
  20. GitLab inbound email issue notificationThis post details a security vulnerability where the `@gitlab.com` domain used for the "create new issues via email" feature could be abused by attackers. It outlines customer remediation steps to update email aliases and whitelisting to `@incoming.gitlab.com` and GitLab's strategy to update addresses and disable old ones. This is a security hardening measure for an existing feature.