Design: Entry points for Secrets Manager

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Collaborate/take over this issue

Problem to solve

Currently, users are using variables to store sensitive information for use in pipelines. This practice introduces security risks, as variables could potentially be exposed in job logs. While masked variables reduce some risks, they do not guarantee complete protection against intentional or accidental misuse.

The introduction of the Secrets Manager aims to provide a dedicated, secure space for managing sensitive data within GitLab. For users to successfully adopt the Secrets Manager, it needs to be:

Discoverable: Users can easily find the feature where they intuitively expect it.
Accessible: Multiple entry points allow users to quickly and securely access secrets within their workflows.

The location of the Secrets Manager and its entry points are key to solving these challenges. Placing the feature in the wrong section or restricting access through a single path could lead to poor adoption, user confusion, and workflow friction.

Proposal

This proposal seeks to address the problems above by identifying the most suitable feature locations and entry points to ensure Secrets Manager is easy to adopt and access in user workflows, and positioned for scalability and expandability in the future.

The proposal is divided into two key parts:

Feature Location 🚪 - The entry door to the Secrets Manager. Where the Secrets Manager could be housed within GitLab, with considerations around user expectations, permissions models, and future scalability.
Entry Points 🪟 - The windows to the Secrets Manager. Identifying multiple ways users can access Secrets Manager, both within their workflows and for quick access to more complex management or configuration.

These solutions are informed by https://gitlab.com/gitlab-org/ux-research/-/issues/3143+ and industry practices, balancing ease of access with security needs and user expectations. The proposed solutions will be validated in a follow-up https://gitlab.com/gitlab-org/ux-research/-/issues/3144+ to ensure they meet user needs and expectations.

1. Feature Location 🚪

The location of the Secrets Manager is a key factor that impacts user experience, security practices, and future scalability. This proposal presents two potential locations, each evaluated based on its alignment with user expectations, workflows, ease of access, permissions model, and long-term usability.

	Dedicated Page for Secrets Manager (🥇 Preferred solution)	Co-locate with Variables (🥈 Alternative Solution)
Why	Why a separate page? Enhanced Security Isolating the Secrets Manager reinforces the idea that secrets require special handling, reducing the likelihood of accidental exposure. Grouping secrets with other features or configurations may undermine the importance of security controls. Support for Complex Workflows A dedicated page accommodates secret workflows that require multiple configurations (such as scope, expiration, rotation) and actions (create, edit, delete, revoke). A dedicated space reduces cognitive load for users managing many secrets. Access Control If Secrets Manager resides on its own page, it is not constrained by the permissions tied to other features/settings on the same page. Future Scalability and Integration Opportunities A standalone page ensures Secrets Manager is ready for future expansion beyond CI/CD (e.g., this internal request outside of CI) without requiring relocation or significant redesign.	Why integrate with variables? Contextual Relevance Many users associate secrets with variables, as both are often used together in pipelines, as shown in problem validation research. Improved Workflow Efficiency Users frequently toggle between variables and secrets for setup and management. Having both on the same page could reduce friction in users’ workflow.
Where	📍Secure > Secrets Manager 👍 Why under Secure? User Mental Model Alignment and Expectation Users naturally associate secrets with security, and this was confirmed as the top location in our tree test results. See problem validation research for detail. Clear Security Practices and Workflow Users responsible for security-related tasks are more likely to look under Secure for Secrets Manager. Isolating sensitive data helps create a clearer mental model for users: secrets are security artifacts, not just configuration elements. Placing the Secrets Manager under Secure ensures it is included in security audit workflows, simplifying compliance reporting and minimizing the risk of misconfigurations. This placement minimizes accidental mismanagement, ensuring only the correct personas with relevant security knowledge handle secrets. Scalability for Use Cases outside CI/CD By placing it under Secure, the feature remains flexible for future extensions beyond CI/CD, and ready for expanding secrets usage to areas like secret detection, etc. 👎 Why not under Secure Users managing both secrets and variables may need to switch between pages, potentially adding friction to user workflow.	📍Settings > CI/CD 👍 Why under CI/CD Settings? Familiar Location Some users associate secrets with variables, and expect to find secrets in CI/CD Settings. This was also confirmed as the second location in the tree test results. See problem validation research for detail. Reduced Navigation Steps Managing secrets alongside variables would streamline the workflow by reducing navigation steps. 👎 Why not under CI/CD Settings? Permissions Misalignment Secrets Manager has its own configurable permissions control, but CI/CD settings are restricted to maintainers only, leading to misalignment. Conceptual Misfit Secrets are not merely settings; but a security feature. Placing them under a settings page may cause confusion about their purpose and usage. UX Challenges and Concerns The CI/CD settings page is already cluttered, with usability issues at scale (e.g., multiple clicks to find features). Adding another feature could worsen the user experience, as shown in problem validation research and user feedback. Secrets workflows may feel constrained on a page that lacks space for dedicated configuration and actions. Adding the Secrets Manager here would increase cognitive load, affecting both the feature itself and other settings on the page.
Design	🖼️ See mockup in Design Section	Suggested temp placement for ~"Tanukey::Experiment" and ~"Secrets Manager:: Closed Experiment" (#470373 (closed)+). 🖼️ See mockup in Design Section
Impact vs. Effort	🟢 High impact 🟡 Medium effort	🟡 Medium impact 🟢 Low effort

Dedicated Page for Secrets Manager (🥇 Preferred solution)

Co-locate with Variables (🥈 Alternative Solution)

Why

Why a separate page?

Enhanced Security
- Isolating the Secrets Manager reinforces the idea that secrets require special handling, reducing the likelihood of accidental exposure.
- Grouping secrets with other features or configurations may undermine the importance of security controls.
Support for Complex Workflows
- A dedicated page accommodates secret workflows that require multiple configurations (such as scope, expiration, rotation) and actions (create, edit, delete, revoke).
- A dedicated space reduces cognitive load for users managing many secrets.
Access Control
- If Secrets Manager resides on its own page, it is not constrained by the permissions tied to other features/settings on the same page.
Future Scalability and Integration Opportunities
- A standalone page ensures Secrets Manager is ready for future expansion beyond CI/CD (e.g., this internal request outside of CI) without requiring relocation or significant redesign.

Why integrate with variables?

Contextual Relevance
- Many users associate secrets with variables, as both are often used together in pipelines, as shown in problem validation research.
Improved Workflow Efficiency
- Users frequently toggle between variables and secrets for setup and management. Having both on the same page could reduce friction in users’ workflow.

Where

📍Secure > Secrets Manager

👍 Why under Secure?

User Mental Model Alignment and Expectation
- Users naturally associate secrets with security, and this was confirmed as the top location in our tree test results. See problem validation research for detail.
Clear Security Practices and Workflow
- Users responsible for security-related tasks are more likely to look under Secure for Secrets Manager.
- Isolating sensitive data helps create a clearer mental model for users: secrets are security artifacts, not just configuration elements.
- Placing the Secrets Manager under Secure ensures it is included in security audit workflows, simplifying compliance reporting and minimizing the risk of misconfigurations.
- This placement minimizes accidental mismanagement, ensuring only the correct personas with relevant security knowledge handle secrets.
Scalability for Use Cases outside CI/CD
- By placing it under Secure, the feature remains flexible for future extensions beyond CI/CD, and ready for expanding secrets usage to areas like secret detection, etc.

👎 Why not under Secure

Users managing both secrets and variables may need to switch between pages, potentially adding friction to user workflow.

📍Settings > CI/CD

👍 Why under CI/CD Settings?

Familiar Location
- Some users associate secrets with variables, and expect to find secrets in CI/CD Settings. This was also confirmed as the second location in the tree test results. See problem validation research for detail.
Reduced Navigation Steps
- Managing secrets alongside variables would streamline the workflow by reducing navigation steps.

👎 Why not under CI/CD Settings?

Permissions Misalignment
- Secrets Manager has its own configurable permissions control, but CI/CD settings are restricted to maintainers only, leading to misalignment.
Conceptual Misfit
- Secrets are not merely settings; but a security feature. Placing them under a settings page may cause confusion about their purpose and usage.
UX Challenges and Concerns
- The CI/CD settings page is already cluttered, with usability issues at scale (e.g., multiple clicks to find features). Adding another feature could worsen the user experience, as shown in problem validation research and user feedback.
- Secrets workflows may feel constrained on a page that lacks space for dedicated configuration and actions.
- Adding the Secrets Manager here would increase cognitive load, affecting both the feature itself and other settings on the page.

Design

🖼️ See mockup in Design Section

Suggested temp placement for ~"Tanukey::Experiment" and ~"Secrets Manager:: Closed Experiment" (#470373 (closed)+).

🖼️ See mockup in Design Section

Impact vs. Effort

🟢 High impact

🟡 Medium effort

🟡 Medium impact

🟢 Low effort

Recommendation

Based on the above, the preferred location is to house the Secrets Manager as a dedicated page under the Secure section. This placement aligns with user expectations, security needs, and future scalability potential.

While co-locating Secrets Manager with Variables under CI/CD settings may offer contextual convenience, the drawbacks - including UX challenges, permissions conflicts, and potential user confusion outweigh the benefits. These drawbacks could be reconsidered if the CI/CD Settings page UX is improved (UX proposal such as #498476) or if an alternative location is identified that works for both Secrets and Variables.

2. Entry Points 🪟

The entry points to the Secrets Manager are crucial in ensuring the feature is discoverable and accessible across user workflows. Findings from problem validation research indicate that users prefer accessing secrets and variables through multiple entry points, with workflow-specific pages and dashboards being favoured, and navigation as a secondary method.

To align with users' preferences, this proposal outlines three key entry points: shortcuts, navigation entry, and in-app search. Each plays a unique role in integrating Secrets Manager into the GitLab user workflow.

	Shortcuts	Navigation	In-app Search	Code-completion support
Why	Problem validation results show users would like to access secrets in their workflow, dashboards or control panel.	Navigation provides a primary access point to ensure users always have a way to find the feature. It follows standard industry practice, as most competitors who offer Secrets Management as part of the platform (not a standalone product) offer the feature directly in their navigation. GCP: Security > Data Protection > Secrets Manager GitHub: Repository > Settings > Security > Secrets and variables IBM Cloud: Resource list > Secrets	Standard GitLab practice to enable feature discoverability through the Super Sidebar search. Search ensures that users can quickly locate and access the feature without needing to memorise its location.	Minimise time spent finding and typing secret keys manually. Integrate secrets into developer workflows makes it easier for users to adopt the Secrets Manager. Reduces friction for developers by aligning with the coding experiences.
What	Link shortcut to feature Adding a quick link to Secrets Manager location for a more complex management. Reference shortcut for usage On the page secrets look up and the ability to copy-paste secret keys in user workflow without leaving the current page.	Add a new navigation entry	Users can search for Secrets Manager and get redirected to the feature	Auto-suggest secret keys within pipelines and scripts Display relevant secret keys or parameters when users are writing YAML files or pipeline configurations.
Design	Link shortcut 🖼️ See mockup in Design Section Reference shortcut 🖼️ See mockup in Design Section	Secure > Secrets Manager (directly under Secure) See feature location section above.	🖼️ See mockup in Design Section	🖼️ See mockup in Design Section
Impact vs. Effort	Link shortcut 🟡 Medium impact 🟢 Low effort Reference shortcut 🟢 High impact 🟡 Medium effort	🟢 High impact 🟢 Low effort	🟡 Medium impact 🟢 Low effort	🟢 High impact 🔴 High effort
Epic/Issue	Add secrets lookup drawer in pipeline editor (#516152)	[FE] Add Secrets Manager sub-menu option under ... (#516128 - closed)	Add Secrets Manager to GitLab global search (#518628)	Code-completion support for secrets in pipeline... (#516151)

Where do we start?

Based on the above proposed ideas and balancing their effort vs. reward, here are the recommendations for prioritising the solution implementation. These recommendations will be validated through https://gitlab.com/gitlab-org/ux-research/-/issues/3144.

Phase 1

Add Secrets Manager as a dedicated page under the Secure section - Aligns with user expectations from problem validation research and follows security best practices. Placing it here provides future scalability without the need for relocation.
Add a new navigation entry based on the above.
Enabling in-app search in the Super Sidebar, ensuring users can easily find the Secrets Manager from the start.
Adding link shortcuts in key areas, such as the Pipeline Editor and Variables, to provide quick access within relevant workflows

Phase 2

Implement reference shortcuts for usage to further streamline secrets usage in user workflow.

Future Iterations

Code-completion support in WebIDE could be considered as a future enhancement to improve the developer experience.

Links

📌 Figma

Edited Sep 05, 2025 by 🤖 GitLab Bot 🤖