Simple masking of protected variables in logs
Problem to Solve
A user may accidently leak a protected variable
Additional Information
In Scope
- For protected variables, also mask them in the job log like we do today for
CI_JOB_TOKEN - Normal variables are able to get masked as well and do not have to be protected as well
- Only variables that match certain requirements will be eligible to be masked
- The secret itself should be a single line,
- The secret should not have escape characters,
- The secret should not use variables,
- The secret should not be with spaces,
- The secret should be required to have some minimal length, like 8 characters.
- When adding a protected variable and/or flagging a variable as protected, we will warn the user if the variable will
notbe masked based on not meeting these requirements
Out of Scope
- This will not add any additional security to variables (which are already encrypted at rest, but we have this epic to improve the actual security of variables: &816)
- There will be limits placed on what will and will not be masked. This will include accounting for enough entropy to make sense (e.g. don't mask a variable that is just set to
a word.) and are not multi-line.
Design solution
Optimal solution
See #59318 (moved)
Minimal solution
- Add masked flag (straining the UI)
- Validation can be done on submit (doesn't require to be done in real time, though nice if possible)
- Masked variables are not accepted unless they fulfill regexp requirements
- Copy changes
| What | Mockup |
|---|---|
| Project variable settings |  |
| error | Warning mockup, see 
|
Example
https://gitlab.com/brendan-demo/ci-variables
Today the output is
$ echo "CI_COMMIT_SHORT_SHA is $CI_COMMIT_SHORT_SHA"
CI_COMMIT_SHORT_SHA is cf14dc21
$ echo "CI_JOB_TOKEN is $CI_JOB_TOKEN"
CI_JOB_TOKEN is xxxxxxxxxxxxxxxxxxxx
$ echo "A_REGULAR_VARIABLE is $A_REGULAR_VARIABLE"
A_REGULAR_VARIABLE is foo
$ echo "A_PROTECTED_VARIABLE is $A_PROTECTED_VARIABLE"
A_PROTECTED_VARIABLE is barAfter this issue is complete the output should be
$ echo "CI_COMMIT_SHORT_SHA is $CI_COMMIT_SHORT_SHA"
CI_COMMIT_SHORT_SHA is cf14dc21
$ echo "CI_JOB_TOKEN is $CI_JOB_TOKEN"
CI_JOB_TOKEN is xxxxxxxxxxxxxxxxxxxx
$ echo "A_REGULAR_VARIABLE is $A_REGULAR_VARIABLE"
A_REGULAR_VARIABLE is foo
$ echo "A_PROTECTED_VARIABLE is $A_PROTECTED_VARIABLE"
A_PROTECTED_VARIABLE is xxxxxxxxxxxxxxxxxxxxPrevious description
It would be cool to have a simple protection of secret variables (e.g. credentials like username, password) in the build log output, mainly to protect against unintentional leaking of secret values
Why?
- In case some software is invoked in the build process shows the password (e.g. debug log or similar)
- Example: testing of chef cookbooks, which access some password protected sources to fetch the software, which is invoked in the test procedure.
- It would be a very easy protection for most cases where some secret might get visible in the log
Solution
- Simple string replacement on secret variable value in build log
- Additional checkbox in the Gitlab UI (see screenshow below)
- Gitlab CI runner gets information if protection is required and does the replacement in the build log
Most variables can be exposed with echo $VARIABLE_NAME. However the CI_JOB_TOKEN is replaced with xxxxxxxxxxxxxxxxxxxx. We should do that same masking to any variable marked as "protected". See https://gitlab.com/gitlab-org/gitlab-ce/issues/13784#note_139304839 for an example project.
Important to note that there are lots of other ways to exfiltrate sensitive information. This would only really protect against unintentional output of sensitive values in the output. This needs to be clear when turning the feature on (similar to the warning in incognito mode in your browser that it isn't truly making you invisible.)