### Overview In https://gitlab.com/groups/gitlab-org/-/epics/2548, plaintext passwords will be removed from the GitLab configuration files for more secure handling of secrets. Customers have expressed interest in a further iteration of our secrets management solution to include support for storing configuration secrets in a secrets management system of their choice. ### Problem to solve While encrypting the plaintext passwords was a good first step in providing a more secure solution for secrets management, it still leaves the encryption keys and secrets stored in files on the same nodes that GitLab is installed on. If a user were able to gain access to the node and the encryption key for the secrets file, they would be able to access the secrets. While many customers are comfortable with their strategy for securing these files, other customers have expressed interest in storing the secrets in a separate secrets management system. ### Proposal If possible, implement a solution that would allow a user to connect the secrets management system of their choice. From [initial customer interviews](https://gitlab.com/gitlab-org/ux-research/-/issues/802), CyberArk was the secrets management system that was most requested. Other requests we've heard are SmartKey and Vault. This is a small sample set. If we can't offer a generic solution that supports the most popular systems we should do more validation to determine the priority order of systems to support. @twk3 mentioned a gem(?) that we might be able to use to support multiple backends. ### Next steps 1. Complete the work included in https://gitlab.com/groups/gitlab-org/-/epics/2548 before picking up this epic 1. Wait for further demand before scheduling this epic. Demand should be collected in the comments of this epic with a Salesforce link to the customer, or a comment directly from an end user. 1. Before designing a solution, check the Vault integration and Identity API work that is being done by the Release team to see if we can use existing work.