This epic contains POC issues as well as blueprint design follow-up issues for the GitLab Native Secrets Manager. ### Goal The goal in this phase is to understand how OpenBao can be used in a multi-tenant environment, what security and performance aspects we need to take in consideration. After this phase is completed we will look into implementing the experimental integration (Rails->OpenBao client, Frontend/UX, production readiness, GDK support, etc.). ### POCs Our two milestone goal (17.1/17.2) is to demonstrate the interaction with the APIs from OpenBao by setting a certain role and understanding what are the secrets that we are able to read. We want to see if and how we are able to interact with OpenBao. Specifically over two milestones, we will: 1. Set project-level secrets (CLI against OB server) 1. Set up policies (templated policies) 1. Use the existing Vault integration to read secrets on Runner (id_tokens) 1. Bonus: explore policies for environment matching and/or protected branches. 1. secrets/namespaces/:namespace_id/secrets + JWT claims 1. secrets/projects/:project_id/secrets + JWT claims 1. Determine how far can we go without namespaces ### Blueprint Follow-ups When we updated [the secrets manager architecture blueprint](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/152167), a number of discussion points were brought up. In order to move forward on the foundations of the blueprint, we created issues for theses discussions. As we move forward with our POCs and flesh out our technical roadmap, these discussions will help us keep track of the questions we still have in regards to the technical implementation. References: 1. OpenBao and multi-tenancy: https://gist.github.com/cipherboy/fecb07bc4fd927d444c6a48e0b497cc4 2. Discussion with Alex ([internal link](https://gitlab.dovetail.com/data/2024-04-30-OpenBao-Q-A-with-Alex-IZrWhfdWZk5ynztSi94VF))