### Problem to solve We plan to implement Vault as a secrets store bundled with GitLab, but some customers will prefer to use an [Azure service](https://azure.microsoft.com/en-us/services/key-vault/). It will be possible to use our provided Vault with GKE (and any generic Kubernetes cluster), but they also provide their own first-party capability. ### Intended users Many developer and operations users will interact with this feature, but the primary integrator will be security operations teams. ### Further details This will provide more flexibility to teams, ensuring that GitLab is valuable even when not using our bundled secrets solution. ### Proposal We should allow for configuration to select a different secrets provider apart from the default provided Vault one. This should be implemented in a way that ### Permissions and Security Implementing this feature will require a comprehensive security evaluation by @gitlab-com/gl-security/appsec. The goal here is to improve security available both to GitLab itself, for CI/CD pipelines, and for users who want to store secrets in general associated with projects under development in GitLab. ### 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 --> We should add to Secrets Documentation ### Links / references