Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Secrets Management

Overview

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.

Vision

By 2024, 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

Why do anything?

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.

Strategy

Pricing strategy

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.

Current Position

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.

Despite the current situation, due to resource constraints we are not actively working on the Secrets Management category. There is no roadmap and there are not plans to ship new features, except for one-off, high-value customer-driven projects. We don't have a product roadmap, and requests are treated and managed as projects.

Next 6 months

Next 9-12 monhts

Create a solid static secret manager within GitLab after invetigating existing open source tools (like Mozilla SOPS) and potential acquisitions.

Next 24 months

Provide an industry-leading secrets management solution within GitLab and improve the HashiCorp Vault integrations. We might bundle the open source version of Vault with GitLab.

Target audience and experience

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.

Jobs

HashiCorp Vault for secrets

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.

Job statements Maturity Confidence Source
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. Badge level - Issue
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. Badge level - Issue

Securely manage secrets

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.

Job statements Maturity Confidence Source
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. Badge level - 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. Badge level - 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. Badge level - 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. Badge level - Issue
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. Badge level - 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. Badge level - 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. Badge level - 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. Badge level - Issue

Maturity Plan

This category is currently at the "Viable" maturity level, and our next maturity target is "Complete": (see our definitions of maturity levels). We don't have a set plan around the required developments in order to move this category to "Complete".

Competitive landscape

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.

Top Customer Success/Sales issue(s)

The top focus for most accounts is to be able to easily integrate with an existing Vault instance.

Top user issue(s)

The most popular issues in Secrets Management are listed in GitLab.

Top internal customer issue(s)

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.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license