## Description This epic enables GitLab Secrets Manager to leverage OpenBao Profiles for single-request management and orchestration of OpenBao from GitLab Rails. OpenBao Profiles allow operators to declaratively define complex multi-request workloads while providing single-API visibility. GitLab will leverage them to improve performance, decrease data loss risks, and simplify migration strategies. ### Problem We're Solving OpenBao Profiles allow operators to define new API endpoints which internally make multiple internal requests, providing a high-level API to a low-level service offering. This reduces latency of multi-request flows and allow operators to provide a facade over OpenBao's raw API. GitLab Rails today often makes multiple requests to OpenBao in handling a single request: - When listing secrets in the dashboard, Rails synthesizes data across the OpenBao list + per-secret metadata endpoints. - When fetching a secret, Rails loads secret metadata and confirms access policies are set. - When updating a secret, Rails writes data, metadata, and updates multiple ACL policies. - When deleting a secret, Rails must delete data and modify or remove multiple ACL policies. Long term, this sets us up for GitLab add-on and better stability. ### How We Solve It - Rails declaratively defines its secret requirements via profiles - The system automatically provisions appropriate secrets based on the profile/role - Enables consistent, scalable secret management across the GitLab hierarchy - Reduces manual configuration and operational overhead - Aligns with GitLab's existing inheritance model for secrets #### Dependencies - Team dependencies: Coordination with OpenBao community for profile specifications leveraging GitLab engineering for community contribution - External dependencies: OpenBao Profiles specification and implementation - Incorporating changes into new release of OpenBao and adopting within GitLab deployment of Secrets Manager - Support and collaboration with ~"group::operate" for any necessary deployment and configuration changes #### References * https://openbao.org/blog/profiles/ * https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/17396 * [Proposal](https://gitlab.com/gitlab-com/content-sites/handbook/-/blob/secrets-manager-future-design/content/handbook/engineering/architecture/design-documents/secrets_manager_plugin_architecture_strategy/_index.md?ref_type=heads#openbao-profiles) #### DRIs * **PM**: `@ashalem` * **EM**: `@mmishaev` * **UX/PDM**: `@jtouchstone1` * **Group(s)**: ~"group::pipeline security" * **Engineering Owner**: `@mmishaev` #### Initiative Driver - Product or Engineering? - [ ] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [x] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated --- ### Hygiene Guidelines :bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - [x] Update epic description with all relevant information - [x] Ensure all dependencies are identified - [x] Apply appropriate labels (see below) - [ ] Apply target delivery Milestone - [ ] Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately