Provide Vault instance for gitlab.com users
Problem to solve
GitLab is adding a per-instance Vault instance to Omnibus via omnibus-gitlab#4317. We could also consider providing a Vault instance to gitlab.com users to store and manage their secrets as well.
This will be used by system administrators to install or define the Vault instance that GitLab interacts with, but services a broad cross-section of users. Security teams will be interested as it provides a mechanism for secure key management (see category page for overall strategic details and benefits.) Specifically, this will be users in this group who are also users of gitlab.com.
This could represent a significant change to compute/storage on gitlab.com. The Vault documentation has details on what is required. It's unclear if we can create one mega-instance for GitLab or if we would need one per-customer. This would drive feasibility of including it as a free feature.
HA is something we would really want if we were using vault with CI runners as any extended outage in getting secrets would delay many of our pipelines. For both infrastructure use and for our customers, we would likely want to be able to survive failures inside a region and failures of an entire region of our cloud provider.
With omnibus-gitlab#4317 implemented, this is a incremental improvement but a complicated one. A proposal for using Vault at gitlab.com scale will need to be investigated by engineering to determine an appropriate path forward to provide this capability. From a product standpoint however we'd want to ensure parity with the managed instance version.
Permissions and Security
In terms of this specific issue, the primary concern is ensuring we follow Vault documentation and build our gitlab.com instance following their security configuration guidance.
We will need documentation on how users can interact with their gitlab.com Vault instance.
What does success look like, and how can we measure that?
We should measure usage of Vault (either configured or installed) by our users