The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Verify |
| Maturity | Minimal |
| Content Last Reviewed | 2023-12-15 |
Thanks for visiting this category direction page on Secrets Management in GitLab. This page belongs to the Pipeline Security group of the Verify stage and is maintained by Jocelyn Eillis (E-Mail).
This category covers the experiences related to variables, pipeline permissions, and secrets. For more information, check out the features page.
This direction page is a work in progress, and everyone can contribute:
Everybody has a secret.
Secrets Management can have a broad meaning. For the Secrets Management product category at GitLab, we have a very specific scope. Secrets Management is specifically about enabling GitLab, or a component built within GitLab to connect to other systems.
The Secrets Management product category does not include the various access tokens created within GitLab that allow other systems to access GitLab or GitLab to access itself. In order to provide an aligned vision and strategy around access to GitLab, these features typically fall under the Authentication and Authorization category.
As Secrets Management focuses primarily on how GitLab can access 3rd party systems, it is tightly coupled to the Environment Management product category.
There are 3 classifications of secrets within the scope of Secret Management:
Ideally, application secrets would never reach GitLab as they are used only within the user's infrastructure and enable one service to access another service, i.e. the database URI deployed into a web application's configuration. The best approach around application secrets would be to retrieve them within the user's infrastructure, without the secret ever leaving the internal network.
In our categorization, static and dynamic secrets are the secrets used to access a 3rd party system by GitLab itself, let it be for a deployment, reporting or any other integration reason. The difference between dynamic and static secrets is their lifespan. Static secrets are … static. They either exist permanently or are revoked or rotated in a separate process. Dynamic secrets are short-lived and their lifespan is often managed by a tool, such as HashiCorp's Vault.
In FY24, we are planning to focus on the following Product Themes:
As we move forward into FY25, we will continue to focus on security, specifically:
In the next 3 months, we will be focusing on:
In milestone 16.8, our team is working on:
In 16.7, our team delivered:
InvalidIdentityToken error. This is now available in production for GitLab.com users and behind a feature flag which will need to be enabled by self-managed customers.In 16.6, our team delivered:
In 16.5, our team delivered:
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
We envision GitLab providing an industry-leading solution for managing static secrets, has loveable integrations with selected third-party secret managers, and provides advanced features (i.e. key management) to ensure best secrutiy practices to fully mitigate the risk of moving application secrets outside customer infrastructure.
The driving principles around static secrets managements are that secrets should be
Every IT project requires secrets. As a result, by not providing a strong offering in this space, we force all security-minded users to have to search for an alternative solution. Without Secret Management out-of-the-box, we fail to fulfill our vision of being a complete single DevSecOps platform.
We also know that a large majority (80%) of customers only require support for static secrets and removing the pain around application secrets, so our investment does not have to be massive. Nor do we have to complete directly with the market leader in Hashicorp Vault.
The biggest question with respect to Secrets Management integrations is to choose the right partners. The Secrets Management market is a fast moving target with a few, well known providers offering their solutions, and a huge number of users not using any of these. Beside HashiCorp Vault, notable offerings are at least CyberAkr Conjur and the Secrets Management offering of AWS, Google Azure and akeyless.
Additionally, Vault Enterprise offers additional sets of capabilities that will not be part of the open source version of Vault bundled with GitLab. This includes replication across datacenters, hardware security modules (HSMs), seals, namespaces, servicing read-only requests on HA nodes (though, the open source version does support high-availability), enterprise control groups, multi-factor auth, and sentinel.
For customers who want to use GitLab with the enterprise version of Vault, we need to ensure that this is easy to switch to/use as well.
In the CICD variables space, GitHub variables, offer comparable flexibility and power. They also offer a differentiation between variables and GitHub secrets, which has set an expectation in the market for a distinct treatment of those objects. We are beginning to investigate this for GitLab in gitlab#217355. GitHub Actions supports injection of HashiCorp Vault Secrets into CICD pipelines, which is directly competing with GitLab's first-to market offering of HashiCorp Vault Secrets in GitLab.
Operations, compliance, security, and audit teams will derive immense value from being able to manage secrets within GitLab. In the motion of shifting security left, developers will also be empowered with the comprehensive treatment of variables and keys as a secrets in GitLab. By prioritizing external key store integrations, we will expand GitLab's security by offering an extra layer for tokens, keys, and other confidential data. This combination of tools will further establish GitLab's presence as an enterprise-grade, corporate solution for Release Management.
As secret handling is a core requirement of every IT project, basic static secret management should be part of GitLab Free. Permissions management, versioning, audit logs around static secrets can be Premium or Ultimate features. Dynamic secrets management with a bring your own device (BYOD) approach should be part of GitLab Free, while support for Enterprise Secrets Management features is to be considered for Premium and Ultimate.
Today GitLab supports environment variables. Environment variables fall short of the basic requirements for secret storage.
GitLab also has decent integration with Hashicorp Vault OSS edition. However, the integration lacks support for Vault Enterprise features.
Lastly, GitLab provides a JWT_TOKEN that could enable access to various 3rd party systems. However, its lack of flexibility and lack of standard compliance restricts its potential.