GitLab Secrets Manager

8/6/2026

This post details the integration of GitLab Secrets Manager with External Secrets Operator (ESO) for Kubernetes, enabling secret synchronization via a Vault provider and JWT authentication. It also introduces support for Terraform and OpenTofu, allowing secrets to be read as data sources using a minted JWT. Additionally, it outlines how to use the Secrets Manager API for external automation and provides CLI examples for OpenBao/Vault. The post highlights the beta status and future billing model.

5/21/2026

This post introduces GitLab Secrets Manager, a new capability for managing CI/CD credentials. It details how secrets are declared in `.gitlab-ci.yml` using the `secrets:` keyword and scoped to specific jobs based on environment and branch attributes. It highlights the use of OpenBao as the underlying technology and emphasizes the integration with existing GitLab access control models for enhanced security and reduced operational overhead compared to standalone vault solutions. The post also outlines the audit logging capabilities for secret reads and management operations.

4/23/2025

This 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.

2/6/2025

This post introduces the capability to scan a repository's full commit history for sensitive secrets using GitLab Secret Detection by setting the `SECRET_DETECTION_HISTORIC_SCAN` variable to `true`. This extends the existing secret detection functionality to cover historical data, including deleted files and branches, thereby enhancing the security posture by identifying and mitigating risks from past secret exposures.

10/31/2024

This post details best practices for preventing secrets from being exposed in public GitLab repositories. It emphasizes limiting public visibility of groups and projects, securing CI secrets by using encryption container technologies like GCP Secret Manager, AWS KMS, and HashiCorp Vault, and leveraging GitLab's built-in secret detection capabilities: secret push protection, pipeline secret detection, and client-side secret detection. It also provides guidance on what to do if credentials are accidentally leaked, including resetting them and revoking tokens.

5/20/2024

Introduces GitLab's native secrets manager, built on OpenBao, for managing secrets within the DevSecOps platform. Details initial focus on CI workflow, integration with secret detection, access token generation, audit logging, and secured artifacts. Highlights the goal of simplifying management, reducing risk, and offering an alternative to third-party solutions.

6/13/2023

This post details the integration of GitLab Secret Detection with Google Cloud for automatic revocation of leaked Google Cloud credentials (service account keys, API keys, OAuth client secrets) in public projects hosted on GitLab.com. This feature is available for GitLab Ultimate users and works by sending detected leaked secrets to Google Cloud for verification and account protection. The post also mentions ongoing work on automatic response for other cloud platforms and GitLab Personal Access Tokens, and expanded protection to all public branches.

2/28/2023

This post details the evolution of GitLab's CI/CD JWT token support, introducing OpenID Connect (OIDC) for broader cloud provider integration (AWS, GCP). It enhances security by making JWT tokens opt-in via the `id_token` keyword in `.gitlab-ci.yml` and mandates the `aud` (audience) claim for token validation. The post also announces upcoming breaking changes in GitLab 16.0, deprecating older JWT methods in favor of the secured OIDC token and advising users to migrate to `id_token` and enable JWT access limitations.

10/3/2022

This 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.

9/28/2022

This 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.

9/20/2022

Introduced 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.

12/2/2021

This post introduces and details the implementation of managing secrets within a Kubernetes cluster using a GitOps approach with Bitnami's Sealed Secrets. It covers the installation of the Sealed Secrets controller, the process of retrieving the public key for encryption, and the workflow for creating encrypted `SealedSecret` resources from unencrypted Kubernetes `Secret` manifests. The post also provides utility scripts to simplify the sealing process and discusses the benefits of Git-based secrets management, such as versioning and collaboration through merge requests.

8/30/2021

This 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.

7/23/2021

Introduced 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.

2/13/2020

This post details the initial approach to integrating GitLab CI/CD with HashiCorp Vault. It discusses two potential MVCs: using GitLab Runner to fetch tokens from Vault (chosen as the simpler solution) or a direct Rails integration. The chosen approach leverages Rails to instruct GitLab Runner, keeping complexity within the Rails app and the runner simple. This aims to provide a secure way for customers to access their stored variables in Vault, with an emphasis on short-lived, rotatable credentials.

12/20/2019

Introduced Token-Hunter, a new tool developed by GitLab's Red Team to scan public GitLab assets (issues, discussions, snippets, merge requests) for unintentionally leaked sensitive data such as API tokens. The tool implements request retries and dynamic page-size reduction algorithms to handle large data pulls reliably. It aims to complement existing secret-scanning tools by focusing on GitLab-specific content types.

3/6/2018

This 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.