Frontend: Define Vault configuration in CI/CD Settings UI
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
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
User experience goal
The user should be able to go to a GitLab Project settings to configure the Vault details for their CI/CD jobs.
Proposal
- 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
andauth path
information using input text. -
auth role
andauth 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.
- Clicking the button should trigger a modal.
Further details
In !31831 (closed), 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 forstages
in thegitlab-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
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?
Is this a cross-stage feature?
No.
Links / references
Inciting MR for feature - !31831 (comment 346730062)