Backend: Add GitLab Native Secrets

Release notes

Previously, it was only possible to configure secrets using the CI variables interface. This made it difficult to prevent revealing the secret variable's value. In this release, we've added the ability to configure secrets in a dedicated section under project settings. Secrets are encrypted and will never be revealed to anyone. This gives you more control and security when managing sensitive information your CI job needs to complete work.

Problem to solve

As a user, I want to use the GitLab UI to store sensitive information my CI job needs to complete work, so that I can easily manage secrets independently from CI variables.

Intended users

• Sasha (Software Developer)
• Devon (DevOps Engineer)

User experience goal

In a project, the user will be able to navigate to the CI/CD > Settings to manage Secrets independently from CI/CD Variables.

Proposal

• The application should encrypt the secret value.
• The secret value should never be available in the UI/API after the secret is created.
• We should allow users to add all characters types to a secret key.
  • If secret key maps 1:1 with the name of the environment variable that is going to be used, we should stick to the validation we currently have for CI variables key
  • https://gitlab.com/gitlab-org/gitlab/-/blob/04c6d8f70686a6633048c1dddab6c918ed20edc0/app/models/concerns/ci/has_variable.rb#L13-17.
• We might try to put a size limit value.
• Secret values can be overwritten in the API but no one should see the values.

Acceptance criteria

⭐ SEE PROTOTYPES ON FIGMA ⭐

• We will add new section under project/-/settings/ci_cd to prevent revealing any secrets values in UI.
• 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 table headers should display: Key.
    • The user should the able to reorder the columns by clicking the header.
  • The user can add a secret by clicking the Add secret button.
  • Clicking the button should trigger a modal.
    • The modal should display a title, body, and action buttons (Cancel, Add Secret).
    • In the body of the modal, the user can enter the Key and Value information using input text.
    • All fields are mandatory.
    • The Add secret button should be disabled until user enters all mandatory information.
    • Clicking Cancel closes the modal. All data is discarded.
    • Clicking Add secret closes the modal and saves the secret to the application. The table should display the a new row for the secret.
      • Only the Key is displayed in the UI.
      • The secret Value should never be available in the UI.

Further details

Users treat secrets differently than CI/CD variables. We are looking to match the expectations for secrets by creating a delineation in the frontend for secrets.

Users should be able to set this at project, group and instance level. We can start with project or group first.

Out of scope

• Update a secret in the UI.
• Delete a secret in the UI.

Permissions and Security

• Members with no access (0) should not access secrets
• Guest (10) members should not access secrets
• Reporter (20) members should not access secrets
• Developer (30) members can access secrets
• Maintainer (40) members can access secrets
• Owner (50) members can access secrets

Documentation

Yes, this will require a new documentation section and an update to our existing secrets docs.

What does success look like, and how can we measure that?

• Numbers of users with a Secret enabled

What is the type of buyer?

GitLab Premium