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.
As a result of conflicting interests inside and outside of every organization, everyone has to use and manage secret variables. The vision and philosophy of supporting users with a comprehensive strategy around pipeline permissions, CI/CD variables, deploy keys, and integrations with external key stores are contained within the Secrets Management category at GitLab.
The first component, environment variables, are dynamically-named values that impact the way running processes behave on an operating system. In CI/CD, these values can be secrets that determine how a job executes. Secondarily, permissions in pipelines are tokens related to how pipelines access other systems inside and outside of GitLab, which is adjacent to the third feature of deploy keys. At GitLab, when deploy keys are enabled, it uses an SSH public key to read or read-write to multiple repositories. This is a useful mechanism for sharing access to deploy between projects and automation for remote machines. Lastly, the fourth feature in Secrets Management is around integration with external key stores, of which we are prioritizing HashiCorp Vault first.
Secrets Management is a complex problem space, and GitLab prefers to integrate well with existing secrets management solutions for enterprise needs, and support lighter requirements out of the box.
Our primary integration target for secrets management is HashiCorp's 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. See the introduction to Vault and our discussion on Vault<>GitLab Integration with our CEO @systes.
There are three main secrets management use cases that Vault will solve for. These are as follows:
Check out the 13.0 release of the GitLab <> HashiCorp Vault Integration:
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.
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). Simulataneous to this, we are beginning to investigate making pipeline permissions more flexible with a proof of concept in gitlab#221192. Lastly, we are expanding audit logs for CICD variables via gitlab#30857.
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 to around the required developments in order to move this category to "Complete".
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.
Deploy keys and tokens are an area where we can complement the GitLab permission paradigm by affording greater flexibility in job permissions. Competition wise, the GITHUB_TOKEN, is comparable and more flexible than the CI_JOB_TOKEN today, which we are working to improve in gitlab&35590.
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.
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
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 compliance and regulatory needs of Secrets Mangement include expansion of Audit events via (gitlab#8070) and the redefinition of a secret as a separate 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 users in their compliance journey.