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 | Software Supply Chain Security |
| Maturity | Minimal |
| Content Last Reviewed | 2024-11-08 |
Thanks for visiting this category direction page on Secrets Management in GitLab. This page belongs to the Pipeline Security group of the Software Supply Chain Security stage and is maintained by Jocelyn Eillis (E-Mail).
This category covers the experiences related to secrets management and CI job token. 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. Examples of these tools include HashiCorp's Vault, Azure Key Vault, AWS Secrets Manager, and Google Cloud Secret Manager.
In the upcoming year, our team is focused on the following:
In the next 3 months, we will be focusing on:
In milestone 17.6, our team is working on:
In 17.5, our team delivered:
In 17.4, our team delivered:
In 17.3, 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 leaders in this space.
To become the best-in-class solution for secrets management, we are focusing on the following key deliverables:
Implement GitLab native secrets manager - This will provide a built-in solution for managing static secrets within GitLab, offering core functionality such as encryption, versioning, and access control.
Enhance CI job token permissions - Implementing more granular permissions for CI job tokens will improve security and flexibility for users managing access to resources.
Improve JWT token support for OpenID Connect - Enhancing our JWT token support will enable better integration with third-party services and improve overall security.
Integrate with AWS Secrets Manager - Adding native integration for AWS Secrets Manager will expand our offering to support users in AWS environments.
Implement secrets management instrumentation - Adding comprehensive instrumentation will provide valuable insights into usage patterns and help inform future feature prioritization.
These deliverables aim to address key capabilities required in a best-in-class secrets management solution, including secure storage, integration with popular third-party services, improved user experience, and enhanced security controls.
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, and Azure.
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. Enterprise Secrets Management (including permission management, versioning, and advanced audit capabilities) are likely to be paid features.
Today GitLab supports environment variables. Environment variables do not meet the need for secure storage of sensitive information. Given our security first positioning, we are building our native secrets solution to address this gap within our existing product.
GitLab has native integrations with Hashicorp Vault, Azure Key Vault, and Google Secret Manager. These are basic integrations, and do not provide full coverage for all enterprise use cases.
Lastly, GitLab provides a JSON Web Token (JWT) that enables access to various 3rd party systems. This option requires additional development effort from the user to set up properly.