The MVP for #17739 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.
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?
note: Text should state:
This variable will be passed only to pipelines running on protected branches and tags.
Links / references
- More general issues: #17739 and #24194 (closed)
- Meta issue: #21911
- Related: #30634 (closed), #20261 (closed), #20368 (closed), gitlab-ee#2302 (closed)
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.