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
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
- 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
andValue
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.
- Only the
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