<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This 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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve GitLab has a number of important secrets that it tracks itself; Kubernetes cluster credentials, credentials for its own database, and so on. We can reduce the attack surface area for these by moving them into an embedded Vault. Being able to split credentials from configuration, has been one of the most oft requested features: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183 ### What's next and why The first step is to how many of the credentials used to operate GitLab are able to be stored in Vault: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4297 ### Security and Availability considerations Security is a complex topic here. From @dblessing in https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4317#note_168324420: > ...I'm somewhat concerned/unsure whether it will be a good idea to colocate customer sensitive data in the same Vault as GitLab application secrets. > > My primary concern is due to the OSS active/passive HA solution for Vault. In a large GitLab instance, if we use Vault for secrets, the availability of Vault will likely be critical to various components being able to start up. Consider that Unicorn workers and Sidekiq processes occasionally recycle and would need to reload secrets from Vault. In this case, what if the customer's usage of Vault for their own secrets is overwhelming the Vault primary and the GitLab components are not able to get their secrets in a timely manner? > > This is completely theoretical. I have no idea how many queries a Vault primary can actually sustain. But I think it's important for us to at least think about this as we move forward. > > Similarly, we should remember that Consul is the backend for Vault. In Omnibus HA environments, Consul is critical to watching and managing DB failover. I'm not sure if it's possible for Vault to overwhelm a Consul cluster but it would be bad if a customer's usage of Vault led to Consul problems. > > Should we consider allowing Omnibus to deploy two completely separate Consul/Vault systems? This would also make it easier for a customer to 'bring your own' for the portion where they want to store their own secrets. We would then keep the Omnibus one for our own secrets. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ### Links / references - Hashicorp Vault plugin: https://github.com/hashicorp/vault-rails