Hide "Secret Variables" by default

Description

We should make secret variables harder to leak accidentally and auditable when viewed.

Proposal

1. Treat all project variables the same
2. In https://gitlab.com/group/project/variables, show keys only with hidden or masked out values
3. Have button to show values (or just rely on the edit button to show the values)
4. Log an audit even for the viewing (EE only?)

I am not a fan of restricting view access to Master or any other role. It just doesn't make sense given that a developer can print out the variables in a CI script. We have a separate proposals for environment-specific variables (#20367 (closed)), role-specific variables (#23861 (moved)), and service-level variables (#23859 (moved)).

Links / references

• environment-specific variables (#20367 (closed))
• role-specific variables (#23861 (moved))
• service-level variables (#23859 (moved))

@ericrange Could you expand on this? Where are these "secret variables"?

Added ~65372 label

right here: https://gitlab.com/group/repo/variables

As written in the docs... you can put your credentials for the ci process right in this place. but im a bit afraid that this credentials are showing in plaintext, everyone can read it.

Removed ~65372 label

This page should only be accessed by owners of the repo so I don't think everyone can read it, but you may be right in thinking that they should initially be hidden although it may be useful to be able to see what you've entered as a Secure Variable at some point in the past.

Added ~19173 ~14106 settings labels

To protect secure variables, that can leak thorough a build log you should configure CI in your project to hide build logs. It can be done for public projects as well.

This has been on my mind for quite some time, as I use Gitlab CI variables extensively, especially for the deploy stage. I was about to create another issue, but will add my thoughts as a comment here instead.

Anyone with Master access to a project can read all secret variables in plain text. This removes the ability to audit access to secrets. Even if secrets are printed out as part of a build, at least you know how and when they were leaked. In the current system anyone with Master access (including the admin of Gitlab) can read the secrets without anyone's knowledge. This is OK for smaller teams, but as the organisation grows it becomes more important to clearly define, restrict and audit access to secrets.

One way to handle this would be to flag some Gitlab CI variables as "hidden", which would hide their values on the variables page.

From there you could further restrict "hidden" variables to only be available on builds on specific branches - this would let you protect variables by protecting branches. Currently, any user with Developer access to the project can, knowing the name of the variable, create a build that echos/prints the secret variable. This cannot be prevented by hiding the build log.

The problem is that even if we remove the content of the secret variables from the web UI, anyone with Master access to the project could alter the .gitlab-ci.yml to use the content of the secret variables and store it somewhere in a build artifact which could then be downloaded.

@cdb That's a good point. However, isn't it better to restrict this to Master level users, rather than any Developer?

Mentioned in issue #22659 (closed)

Added ~113220 label

Relevant Zendesk ticket: https://gitlab.zendesk.com/agent/tickets/40708

Mentioned in issue #13784 (moved)

Another customer requested this: https://gitlab.zendesk.com/agent/tickets/40980

@markpundsack Maybe for the next CI plan? Or is this not done yet from a product perspective?

Mentioned in issue #20368 (closed)

Proposal:

• Treat all project variables the same
• In https://gitlab.com/group/project/variables, show keys only with hidden or masked out values
• Have button to show values (or just rely on the edit button to show the values)
• Log an audit even for the viewing (EE only?)

I am not a fan of restricting view access to Master or any other role. It just doesn't make sense given that a developer can print out the variables in a CI script.

We have a separate proposal somewhere for environment-specific variables, and I believe we've discussed letting variables be restricted to different roles, but it would be consistently applied. i.e. if a variable is for Masters only, it would be read-write for them, and non-existent for everyone else. That way if you wanted to restrict deployments so developers couldn't access production systems, it would work. But then those developers wouldn't be able to trigger a deploy at all either. Anyway, that proposal isn't fully fleshed out yet so shouldn't be a blocker for this.

If the above proposal works, I'd be fine with proposing it for 8.14.

/cc @ayufan @dimitrieh

At the risk of sounding like a broken record: Another customer just requested this: https://gitlab.zendesk.com/agent/tickets/44680

And they are happy with @markpundsack proposal for The Button that Logs.

I think this makes sense as an EE only feature. Could we please consider it for 8.14?

@markpundsack was this the issue you were talking about? https://gitlab.com/gitlab-org/gitlab-ce/issues/22436

it also talks about how to be able to show these values.. I would be fine with hiding them, but they need to be visible to the right people

maybe you could do this like github. everytime you want to see "critical" information, authenticate yourself right before that.

1. *-Passwords
2. Click on "show passwords"
3. authentication
4. see passwords.

@dimitrieh Environment-specific variables is #20367 (closed). I created new issues for Role-specific variables (#23861 (moved)) and Service-level variables (#23859 (moved)).

Milestone changed to %Backlog

Added ~19492 ~897282 labels

Added ~123454 ~131895 labels

@ericrange That's a good suggestion, but seems like something we can do in a second iteration. Having a button to show the variables means less accidental disclosures and the ability to log to the audit trail. Asking for your password before showing variables would slightly decrease the chance of someone using your laptop/phone to access them, but with browsers autofilling passwords, that's not much of a safety net these days.

Would the proposal in https://gitlab.com/gitlab-org/gitlab-ce/issues/21358#note_16985861 satisfy your immediate needs?

Changed title: Why do you show "Secret Variables" as plaintext? → Hide "Secret Variables" by default

Mentioned in issue #13598 (moved)

Mentioned in issue #21911 (moved)

We have customers actively updating each month and checking to see if it has made it in https://gitlab.zendesk.com/agent/tickets/44680

Removed ~897282 label

/cc @dimitrieh

Mentioned in merge request !7731 (merged)

Take a look at !7731 (merged) and see if this would suffice as a first pass.

@markpundsack does the removal of ~"coming soon" mean it will be scheduled for this release?

as for the design, i think https://gitlab.com/gitlab-org/gitlab-ce/issues/22436#note_16540098 already had some pretty good ideas, resulting in this design for secret project variables:

Current situation looks like (looks like this after unlocking as well):

Designs:

Mentioned in issue #24196 (closed)

@dimitrieh

It seems like a good next iteration. I believe that for now we should be more than happy with what @stanhu did: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7731.

The Secret Variables can be accessed only by Master. We also have a second issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/24196) to lock the use of them for pipelines triggered only by masters.

@ayufan alright!

Removed ~19492 label

@dimitrieh Thanks. Can you create a new issue to track that iteration? Personally, I like seeing the variable keys and having the values masked rather than hiding the entire section, but we could add a password verification after clicking on the Show button. At any rather, this satisfies my immediate needs, so puts the password check at a much lower priority.

Status changed to closed by merge request !7731 (merged)

Mentioned in issue #25100 (moved)

@markpundsack done! https://gitlab.com/gitlab-org/gitlab-ce/issues/25100

mentioned in issue #25516 (closed)

mentioned in issue gitlab#6127