Secret variables are NOT output to Gitlab CI job logs... but if someone echos them, they WILL appear in the log. This may be obvious to some, but, I like to point it out nonetheless.
You've missed the important detail: Protected Variables in Gitlab aren't just hidden, they're not injected into builds which don't happen on Protected Branches.
What this means is that so long as I or another trusted person reviews the PR of a protected branch build, we can have high confidence the code isn't going to disclose secrets unintentionally, and that people aren't going to accidentally modify a build so it deploys outside the process.
This is great! But what I want is for it to go further - in a perfect system, I'd be able to set per-branch variables which are omitted if you're not on the right branch, and have branch protection managed by different sets of users - i.e. developers, lead developers, then testing/QA/UAT and finally production - which could just correspond to branch rules like uat/<whatever> preprod/<whatever> prod/<whatever> and allow PRs with different approvers to control the escalation process.
I think it would be a good feature to hide secrets from the log by searching for them and replacing them with something like [removed]. It would be best if it were done by a component that had the security locked down (maybe a process that you pipe it through) and it wouldn't prevent users from encrypting it to bypass the filter, but it would make it harder for misbehaving users to deny that they circumvented the security. It could also detect JSON stringified or base64'd secrets.
Wouldn't this be an unwinnable battle? If you can't print out the whole secret, you can print out each half of it, or one character at a time, each on a different line.
There's probably no way around the reality that users who have the ability to run arbitrary code on the CI server have access to the secrets.
Yeah. Maybe I shouldn't have suggested scrubbing base64'd secrets. What I have in mind is a usability feature, making it so users can't accidentally print out a secret that they're not supposed to print out.
I would have to admit that's useful as I've accidentally printed a secret key or two to publicly accessible jobs on TravisCI, and then had to scramble to rotate them :)
And now I'll take the secret, base64 it, add a space between each character, reverse the order and base64 it again. And then toss it through a round of AES256 with my key, all before echoing it.
Trying to prevent people from exfiltrating data by filtering the output stream is an impossible battle.
It wouldn't stop outright, and I tried to communicate that I knew it wouldn't in my comment. It would make it so if someone got caught doing that, it would be harder for them to deny that they did it deliberately, and you could throw the book at them. As it is now, they could print it out and say that they were just debugging, or they could even think it was permissible to print it out.
I can see the point of removing plausible deniability - it's just that I'm of the opinion that if something is known to be insecure it shouldn't try to pretend otherwise.
What this means is that so long as I or another trusted person reviews the PR of a protected branch build, we can have high confidence the code isn't going to disclose secrets unintentionally, and that people aren't going to accidentally modify a build so it deploys outside the process.
This is great! But what I want is for it to go further - in a perfect system, I'd be able to set per-branch variables which are omitted if you're not on the right branch, and have branch protection managed by different sets of users - i.e. developers, lead developers, then testing/QA/UAT and finally production - which could just correspond to branch rules like uat/<whatever> preprod/<whatever> prod/<whatever> and allow PRs with different approvers to control the escalation process.