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.
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.
What is not included as part of the Secrets Management product category are 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:
In an ideal situation application secrets would never reach GitLab as they are used only within the user's infrastructure and enable one service to access another service, like 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.
GitLab provides an industry-leading solution for managing static secrets, has loveable integrations with selected dynamic secret managers, and provides best practices to avoide the risk of moving application secrets outside their 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.
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.
Until a team is designated to address secrets management, our main focus will be on improving the current variables and JWT capabilities. In FY24, we are planning to support the following Product Themes:
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.
When I need to use a secret/token/password I want to use my HashiCorp Vault so I can leverage the tool I am already using for Secrets Management.
|When I need to use a secret/token/password for a pipeline I want to authenticate into HashiCorp Vault, pass the secret to the CI Job and execute the pipeline so I can leverage the tool I am already using for Secrets Management.||Issue|
When I am deploying changes to environments outside of GitLab I want to easily authenticate and pass the appropriate secrets between GitLab and the environment without exposing the secret so I can deploy my changes to production quickly.
|When I am using secrets for pipelines I want to be able to access those secrets easily and from a single place so I can deploy my changes to production quickly.||Issue|
|When I am working with tokens or passwords I want to keep these secret and avoid revealing the values in an audit log or to other developers so I can maintain secrets management best pratices and avoid a breach of data.||Issue|
|When I am enforcing compliance standards for passwords, tokens, and secrets I want to be able to set automated secret rotation so I can avoid disrupting developers workflows and being in breach of compliance.||Issue|
|When I am accesing a system to deploy my change to an environment I want to be able to access the system without leaving my CLI to log in so I can deploy my changes to production quickly.||Issue|
This category is currently at the "Minimal" maturity level, and our next maturity target is "Viable": (see our definitions of maturity levels). Where we plan to move GitLab JWT token from Alpha into production, this way users will be able to authenticate agains other third parties (such as AWS, GCP, akeyless) to retrieve their credentials using GitLab CI.
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.
The top focus for most accounts is to be able to easily integrate with an existing Vault instance.
The most upvoted
internal customer issue in Secrets Management is around usability of build variables in gitlab#17069. The second top issue focuses on building out audit logs for CICD variables via gitlab#30857.
Additionally, our infrastructure and SecOps teams are proceeding to invest in moving GitLab's own secrets into Vault.
Internally, once the Vault integration is available we can begin moving some of the secrets tracked internally in GitLab to the included Vault.
db_key_basesecret to be rotated