HashiCorp's Vault is paving the way for OSS Secrets Management and many of our customers are leveraging the solution today. Vault lets you easily rotate secrets and can manage intermediate, temporary tokens used between different services. This ensures there are no long-term tokens lying around or commonly used. Vault minimizes GitLab's attack surface and protects against any unknown zero-day vulnerabilities in our Rails app today or those that allow a bad actor to access the Gitlab server by ensuring that GitLab does not hold any long term secrets.
There are three main secrets management use cases that Vault will solve for. These are as follows:
Operations, compliance, security, and audit teams will derive immense value from being able to manage secrets within GitLab. Vault 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.
Now that we can effectively authenticate Vault with GitLab from (gitlab#9983), and users can install Vault into a Kubernetes clusters via (gitlab#9982), we are devoting more time to handling CI Variables from Vault. Users can now authenticate using a JSON Web Token via (gitlab#207125), to then fetch and read secrets from Vault via the implementation of (gitlab#28321).
Check out the 13.0 release of the GitLab <> HashiCorp Vault Integration:
This category is currently at the "Minimal" maturity level, and our next maturity target is "Viable": (see our definitions of maturity levels).
Key deliverables to achieve this are:
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.
The top focus for most accounts is to be able to easily integrate with an existing Vault instance. We will render the most value from this after we deliver (gitlab#28321), which will support the fetching and reading of secrets from Vault for CI jobs. Fit and finish features like managing secrets in the GitLab UI as described in (gitlab#218677) will reduce the barriers of entry between using Vault and GitLab together.
Our most popular issue is managing Vault secrets inside Gitlab (gitlab#20306). We will likely deliver on (gitlab#218677) to define Vault configuration in GitLab for CI/CD jobs and measure consumption before investing in a greater UI experience.
We have considered bundling Vault in Omnibus via (omnibus-gitlab#4317), due to it's popularity. Upon futher investigation, many of our users have an existing Vault and there is little tolerance for reconfiguring to use a GitLab provided Vault. Delivering a best in class integration and managed application will deliver on this need.
Our infrastructure and SecOps teams are proceeding to invest in moving GitLab's own secrets into Vault.
Expanding the prescriptive use cases for Vault in GitLab prior to investing in development effort is currently being considered in (gitlab-org&2365).
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
The MVC for migrating our internal secrets is being tracked in the epic to move GitLab's own secrets into Vault. Supporting GitLab internal secrets, does require the Vault integration being mandatory as part of the install first.
Secrets management is a must-have for enterprise-grade release governance. Adding a proper interface to Vault (gitlab#20306) embedded in GitLab, would make it easier to interact with the Vault instance. The interface can be leveraged for all secrets, which would also be a competitive feature set for the Operations-centered and security minded buyers within the regulated space.
We are learning about the desire for there to be a greater differentiation for secrets and CICD variables via gitlab#217355. Users are rightfully expecting secrets to be truly secret to avoid leaking credentials unintentionally. This split will afford a greater fine tuning of variables within GitLab.
Features to deliver on the complaince and regulatory needs of Secrets Mangement include expansion of Audit events via (gitlab#8070) and the redefinition of a secret as a seperate entity in (gitlab#217355). Secrets are treated differently than CI/CD variables in practice although GitLab does not distinguish the experience for our users. Investing in this separation and tracking will help our position in the Zero Trust Wave and support our user's in their compliance journey.