### Release notes GitLab has selected Vault by HashiCorp as the first supported provider, and KV-V2 as the first supported secrets engine. Previously, it was only possible to configure your Vault server to use JWT through the API. In this release, we've added the ability to provide details about your Vault server in the settings page of a project. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> As a user, I want to define configuration for my secret provider using GitLab's UI, so that I can safely use external secrets in my CI jobs. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) <!-- * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to go to a GitLab Project settings to configure the Vault details for their CI/CD jobs. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ⭐ [`SEE PROTOTYPES ON FIGMA`](https://www.figma.com/file/Fksq4wWcpAYOcPYW8VIcGv/Secrets-Management?node-id=1%3A98) ⭐ * We will add new section under `project/-/settings/ci_cd` for external secret providers, where users can provide the values for configuring their Vault server. * The values should be related to the following variables: ``` VAULT_SERVER_URL - The URL of your Vault server, such as https://vault.example.com:8200. Required. VAULT_AUTH_ROLE - (Optional) The role to use when attempting to authenticate. If no role is specified, Vault uses the default role specified when the authentication method was configured. VAULT_AUTH_PATH - (Optional) The path where the authentication method is mounted, default is jwt. ``` * The section should be expandable/collapsible. * ~frontend replicate existing pattern using the ~"component:accordion" * https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-collapse--default * A title, description, and help text should be present. * ~"Technical Writing" needs to review ~"UI polish" * ~frontend A table component should be used to display the secrets. * An empty state should be displayed when no items are added. * The user should the able to reorder the columns by clicking the header. * The user can add a secret by clicking the `Add external secret provider` button. * Clicking the button should trigger a modal. * The modal should display a title, body, and action buttons (Cancel, Add). * In the body of the modal, the user can enter the `server url`, `auth role` and `auth path` information using input text. * `auth role` and `auth path` are optional. * The `Add` button should be disabled until user enters all mandatory information. * Clicking `Cancel` closes the modal. All data is discarded. * Clicking `Add` closes the modal and saves the details to the application. The table should display the a new row. ### Further details In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31831, we decided that we do not want to support the level of configuration for Vault in the `.gitlab-ci.yml` and there needs to be a frontend/GUI for users to configure Vault. * Add a section under project settings that is for configuration of the Vault URL path, roles that are relevant for Vault and other details * This implementation is to avoid the supporting `types` syntax for `stages` in the `gitlab-ci.yml`. * Improve the user experience in configuring Vault. * Provide a single place of administration for Key Stores. ### Out of scope * Edit a secret provider in the UI. * Delete a secret provider in the UI. ### Permissions and Security Maintainers and admins should be the only ones with access to this UI component following in line with CICD Variables. * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members ### Documentation We will need documentation added to https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/ ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? * Users adopt the HashiCorp integration * Users are configuring Vault in GitLab UI ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Premium" ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> No. ### Links / references Inciting MR for feature - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31831#note_346730062