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

Category Vision - Secrets Management

Secrets Management

Hashicorp Vault is a powerful secrets management tool that we are seeing more and more of our customers using, and that we've become big fans of over time. Vault lets you easily rotate secrets and can manage intermediate, temporary tokens used between different services, ensuring that there are no long-term tokens lying around or commonly used that would be valuable to an attacker. This will add protection against any unknown zero-day vulnerabilities in our Rails app today, as well as any zero-day issues that would allow a bad actor to access the Gitlab server.

Since Vault is an open source tool, our vision is to embed Vault within GitLab and migrate to using it for our own secrets management, within the GitLab Core as well as for your CI Runners. Furthermore, this Vault instance would be exposed for your own internal use for your own secrets. In this way we can provide a comprehensive secrets management solution, for all of your secrets, built right into GitLab.

See also an introduction to this feature from our CEO @sytses.

Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.

Target audience and experience

Operations teams tasked with managing secure credentials will be the primary user of this feature. Compliance is quite complicated, and Vault can make it much easier. Additionally, governance teams (such as compliance, security, and audit teams) that are responsible for managing GitLab as a corporate solution will find value here, knowing that there is an additional layer of security built in to GitLab helping to ensure that secure tokens and other confidential data in GitLab is even more protected than it is today.

What's next & why

The first thing to achieve is enabling a Vault installation to be part of the omnibus (omnibus-gitlab#4317) package, which comes for free bundled with GitLab. This is the foundation upon which we can build a deeper integration for moving GitLab's own secrets and CI-related ones, but adds value immediately by being a place a customer can store their own secrets. Adding the same capability to gitlab.com is possible, but quite complex so is being researched in its own issue gitlab-ce#61551. Similarly, installing in Kubernetes gitlab-ee#9982 is an option for the future.

There is also a parallel effort to enable accessing Vault secrets from CI Runners that is being designed to be compatible both with this proposed built-in Vault as well as any other external one.

Maturity Plan

This category is currently at the "Planned" maturity level, and our next maturity target is Viable (see our definitions of maturity levels). Key deliverables to achieve this are:

Further, depending on complexity and cost, making Vault available for gitlab.com users would also be ideal to include.

Related is moving GitLab's own secrets into Vault instead of storing them inside of GitLab.

Competitive landscape

There are other secrets management stores in the market. There is a nice overview of Vault vs. KMS which contains a lot of information about why we believe Vault is a better solution for secrets management. We could consider in the future also supporting different solutions such as KMS.

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.

One issue that will help establish us in the competitive landscape is to offer authentication in Vault using GitLab, via gitlab-ee#9983. This will help users of Vault ensure that interacting with GitLab and Vault is easy and natural.

Top Customer Success/Sales issue(s)

Adding a Vault instance to omnibus installations that can be used for customer secrets is the right first place to start. Additional features will be added on, but this will meet the goal of providing a secrets management solution with GitLab (omnibus-gitlab#4317).

Top user issue(s)

Adding a Vault instance to omnibus installations that can be used for customer secrets is the right first place to start. Additional features will be added on, but this will meet the goal of providing a secrets management solution with GitLab (omnibus-gitlab#4317).

Top internal customer issue(s)

Internally, once the Vault integration is available we can begin moving some of the secrets tracked internally in GitLab to the included Vault.

The MVC for migrating our internal secrets is being tracked in gitlab-ce#61632

This does require the Vault integration being mandatory as part of the install first.

Top Vision Item(s)

Having a Vault instance guaranteed available is table stakes, but beyond this we can add a proper interface to Vault gitlab-ce#40720 embedded in GitLab, making it easier to interact with the Vault instance. This can be leveraged for CI/CD, but also for any secrets that a customer might have in their platform. This will be expanded up on via gitlab-ee#7569 which introduces automatic rotation / dynamic secrets.