### **Problem Statement** GitLab Secrets Manager has low discoverability with multiple friction points to that will limit adoption over time. Three root causes have been identified: 1. Secrets Manager must be manually enabled per group or project. Users only encounter it by chance through documentation or settings exploration. 2. The settings to configure Secrets Manager are buried within GitLab's long-standing general settings list, making organic discovery unlikely. 3. Only group or project owners can initiate setup or management while at the same time this role is sparsely assigned across most organizations. --- ### **Solution** #### Iteration 1: Automatic Availability After Opt-In **Problem:** Secrets Manager must be manually enabled per group or project by an owner. This creates redundant provisioning steps and, as a side effect, forces a page refresh before Secrets Manager appears in navigation. **Solution:** Once a top-level group admin or instance admin opts in to Secrets Manager, make it automatically available and reachable at every level of the group and project hierarchy without any additional manual steps. The navigation entry should appear without requiring a page refresh. **Assumptions:** Top-level and instance admins retain the ability to opt out entirely. **Dependencies:** https://gitlab.com/gitlab-org/gitlab/-/work_items/596562+ --- #### Iteration 2: Expanded Role Permissions for Secrets **Problem:** Only group or project owners can create or manage secrets at start. This role is sparsely assigned in most organizations, severely limiting who can act on Secrets Manager even when it is enabled. **Solution:** Extend roles to fine-grained permissions list to the Secrets Manager * Allow Maintainers to create + update + read secrets metadata for projects * Allow Developers to create and read secrets metadata for projects Maintainer and Developer role should be removable in permissions dropdown. --- #### Iteration 3: Permissions Consolidated into Secrets Manager Page **Problem:** Secrets Manager permissions are located within the general settings list, making it difficult for group and project owners to find them even once they know Secrets Manager exists. **Solution:** Surface the relevant permission controls directly within the Secrets Manager page itself, eliminating the need for owners to navigate away to general settings. **Assumptions:** Iteration 1 has shipped. Secrets Manager is reachable at all hierarchy levels before this work begins. --- #### **Goals** * Increase the percentage of groups and projects actively using Secrets Manager within 30 days of each iteration shipping. * Increase the number of unique users using GitLab Secrets Manager **Baseline metrics to establish before Iteration 1 ships:** % of groups/projects with Secrets Manager enabled, median time-to-first-secret. --- ### Acceptance Criteria ##### Iteration 1: Automatic Availability After Opt-In - [x] When a top-level group admin or instance admin enrolls Secrets Manager (through trial or enable add-on), it becomes automatically available at all child group and project levels without any additional manual steps per group/project. - [x] The Secrets Manager navigation entry appears at every level of the group and project hierarchy immediately after opt-in, without requiring a page refresh. - [x] No regression: groups and projects that previously manually enabled Secrets Manager continue to have access after this change ships. ##### **Iteration 1.5** - [x] Top-level group owners and instance admins can unenroll Secrets Manager, which removes it from all child levels. They are prompted with a warning modal. - [x] Move TLG Settings from General to Secure. Keep other levels in General. - [x] Replace `Beta` grey badge with `New` blue badge on GitLab Secrets Manager heading - [x] Empty state should say `Secure your sensitive information` in all scenarios - **_remove Introducing GitLab Secrets Manager_** --- ##### Iteration 2: Expanded Role Permissions for Secrets - [x] Remove "Group" tab from permissions table. - [x] Maintainers can create secrets + update + read secrets metadata at the project level by default. - [x] Developers can create secrets and read secrets metadata at the project level by default. - [x] Owners can remove Maintainer or Developer from the Secrets Manager permission access list. - [x] Removing a role from the permissions list immediately revokes that role's ability to perform the function it was granted - [x] Permissions changes are reflected in the UI without requiring a page refresh. - [x] Keep permissions table in settings. - [x] Make "Roles" the first tab in permissions table. - [x] No privilege escalation: Developers and Maintainers cannot delete secrets unless otherwise granted. --- ##### Iteration 3: Permissions Consolidated into Secrets Manager Page (Not Scheduled) - [ ] Secrets Manager permission controls (previously in general settings) are surfaced directly on the Secrets Manager page. - [ ] Group and project owners can view and modify Secrets Manager permissions without navigating away from the Secrets Manager page. - [ ] The permissions controls in general settings are removed. - [ ] All permission changes made from the Secrets Manager page are functionally equivalent to those previously made in general settings. - [ ] The feature is only available after Iteration 1 has shipped (Secrets Manager is reachable at all hierarchy levels). - [ ] No data loss or permission regression occurs during the migration of settings location.