We’re trying to set up continuous deployment from GitLab to our staging AWS. (We’re using gitlab.com, and we have “Silver”, in case it matters.)
Out plan was to put an “aws_secret_access_key” for an IAM account that can do the deployment into a GitLab variable that would be both protected and masked. However, when we enter the key, the GitLab UI reports “This variable will not be masked”.
The problem seems to be that the secret key contains “/” and “+”. From looking at a few aws_secret_access_keys, it looks like they are base64-encoded, which means they’ll consist of letters, numbers, pluses and slashes (and theoretically equal-signs, though I think they are sized to prevent this from happening in practice). GitLab appears to be using a regex that only allows values that are 8 or more alphanumeric + underscore characters to be masked.
What are other people doing for continuous deployment to AWS? Does it make sense to store an aws_secret_access_key in a GitLab variable?
If storing an aws_secret_access_key in a GitLab variable is reasonable, then how do we get it to be masked? In my searches I found people suggesting the use of base64 for storing things like ssh-keys, but that won’t actually work given how strict the masking regex is.
We did notice that this masking regex (at least the commit that added the line I linked to above) is only a few weeks old, which makes us wonder if others haven’t run into (or at least reported) this problem yet. Could this regex be loosened up a bit to allow base64 encoded values?
It actually doesn’t seem to matter what you use for a secret value, the same “This variable will not be masked” is displayed, and for us, this is a complete show stopper in regards to gitlab.com
@binarymist, did you try entering more than 8 alphanumeric characters? If I enter “12345678” it doesn’t say “This variable will not be masked”, but anything shorter, or anything containing a non-alpha/numeric/underscore character produces the error.
As a work-around we’re considering using base32. For AWS keys, something like this works:
$ echo npSaqbp7c+DMgtNw0ZiN7xQJ8rCIgFsqTyV2O/rW | base64 -d | base32
$ echo T2KJVKN2PNZ6BTEC2NYNDGEN54KAT4VQRCAFWKSPEV3DX6WW | base32 -d | base64
(“npSaqbp7c+DMgtNw0ZiN7xQJ8rCIgFsqTyV2O/rW” is not an actual AWS secret key, but has the same format)
The first command converts it to binary and then base32 encodes it, the second converts it back to the original base64.
The entire base32 alphabet is compatible with GitLab’s masking regex, except for the pad character, “=”. AWS secret keys seem to be 240-bits, a multiple of 40, so there isn’t any padding. A more general solution could use
tr to transform the padding to/from underscores (which are also allowed by GitLab’s regex)
Still, it’d be much nicer if we could just use the key as-is without going through all of these contortions. I don’t know why they didn’t just make the requirement “8 or more ASCII, non-space, printable characters”. If they’d at least add
[+/=] to the set of allowed characters then base64 would work, even with padding, and AWS keys would work as-is.
Oh, interesting. No I didn’t.
Thanks for your response (workaround) @xenomachina, OK, so looks like this is not a show stopper.
Agree with everything you’ve said. I didn’t want to spend too much time on this unless I knew it’d work and our secrets could remain secret.
At least it looks like we can move forward with deploying to AWS.
Is this on a protected branch?
@scot.mcphee, I’m not sure what you’re asking.
Under a project’s Settings → CI/CD → Variables, variables can now be separately set as “protected” and “masked”. (That’s the way it is on GitLab.com — I don’t know what version this was added in, but it seems to be pretty recent.) This discussion is just about masking, not protecting.
Related issue: Allow more special characters in masked variables
Go upvote it if you care about this.