Add option to mask variables in runner config.toml from CI job output
Problem to solve
Secrets found in GitLab Runner's config.toml variables can be included in CI job output.
Using echo or cat with variables like CI_SERVER_TLS_CA_FILE in a GitLab CI job can include the values in the job output. This is by design, expected behavior, and is helpful in situations like Debug tracing.
However, with no merge restrictions in place for the GitLab CI job files, an authorized user can unintentionally or maliciously modify a CI job to output and expose CI variables containing secrets.
This can usually be avoided by using of Masked variables.
However, this is not currently an option if passing the variables directly at gitlab-runner register or if stored in config.toml.
Intended users
Further details
Using masked variables can help in many cases, but not when secrets are passed as variables during gitlab-runner register or set in `config.toml.
Proposal
Add an option to hide secret-containing CI variables from the output of job logs, even if they are contained in config.toml or passed during gitlab-runner register.
Permissions and Security
By default, sensitive CI variables are not included in GitLab CI job output. For CI variables to be included in job output a user with Developer, Maintainer, or Owner access must merge changes to updates files used in a CI job. The ability to merge changes of this type should ideally be restricted and require approval. These restrictions are effective in minimizing risk, but this is not something that GitLab can set up or enable by default.
Documentation
If a feature is implemented: Document on how to mask/hide/exclude variables in config.toml from GitLab CI job output
If not: Clearly outline any/all steps a user or customer can take to secure CI jobs and prevent user behavior like this from occurring
Testing
What does success look like, and how can we measure that?
An admin can easily prevent any config.toml variables containing secrets from being output in job logs. The feature is introduced with minimal impact, no regressions - keep all existing GitLab CI functionality and features fully operational.
Alternatively, documenting steps to effectively prevent users from being able to expose variables in CI jobs with minimal impact on SDLC workflow might be an acceptable workaround.
What is the type of buyer?
Ultimate and Premium customers with security and compliance requirements.
Self-managed Premium and Ultimate customers.