Skip to content

GitLab Next

Open
Created by Jackie Porter@jreporterDeveloper0 of 6 tasks completed0/6 tasks

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

⭐ SEE PROTOTYPES ON FIGMA ⭐

  • 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.
  • A title, description, and help text should be present.
  • 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 !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 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

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?

GitLab Premium

Is this a cross-stage feature?

No.

Links / references

Inciting MR for feature - !31831 (comment 346730062)

Edited by Rayana Verissimo