Protect variables

Description

The MVP for #17739 (moved) and #24194 (closed) might be a simple checkbox to "protect" variables and runners to limit them to users with Master permission, rather than specifying branches. Obviously being able to have different variable values for different branches is a beneficial feature as well, but that shouldn't get in the way of solving the most immediate security concern. The verbiage of "protecting" the variable has a nice parallel with protected branches too. And the checkbox is easily extendible to then show a dropdown of roles or branches to link variables and runners to.

Proposal

* Add checkbox to project variables to "protect" them. * Protected variables would have their keys shown to other Developers, but their values would be hidden to all except Masters. * Hidden variables would have some kind of `--protected--` redaction so other viewers know the variables exists, that it's hidden, and why. * Protected variables would *not* be passed to pipeline jobs, unless the triggerer is Master * Exception: If the protected branches allow non-Masters * Add checkbox to project runners to "protect" them. * Protected runners would be visible like normal, but only manageable by Masters. * Protected runners would only be allowed to run on pipelines triggered by a Master. * The checkboxes would of course only be available to Masters.

Alternate Proposal

Similar to above, but instead of tying to Master role, tie it to protected branches. In many cases, this will be functionally equivalent, but could be more powerful. Specifically:

  • Protected variables would only be passed to jobs running on a protected branch, whether that is triggered directly by a Master, or via a merge of a MR where the Developer or other role is "allowed to merge" into the protected branch.
  • Protected variables would not be passed to pipelines running on non-protected branches, even if the triggerer is Master.
  • Protected variables would not be passed to pipelines for tags, since they have no associated branch. (This might be the Achilles heal of the proposal.)
  • Manual actions (e.g. to deploy to production) would not receive protected variables unless they happen to be for protected branches.
  • Likely depends on #30634 (closed).

Question: If we don't go with the alternate proposal, is it possible to augment the first proposal to handle the exception of a Developer or other allowed person merging a MR into a protected branch, and getting the protected variables and protected runners?

Design

image

note: Text should state: This variable will be passed only to pipelines running on protected branches and tags.

Links / references

Documentation blurb

Protected variables are very useful if you want to secure even further sensitive information in your pipelines. Marking a secret variable as "protected" makes it available only to jobs running on "protected branches", and in this way only who has access to these branches (normally Masters) can use them. Secret tokens and credentials for deployment to production are good examples of how this feature could be leveraged to avoid unauthorized access to your infrastructure.

/cc @dimitrieh @ayufan

Edited by Mark Pundsack