Some folks on my team have requested to put values retrieved from a secret store (AWS Secrets Manager) into the Gitlab CI “artifact” construct, and pass them along to downstream stages.
I feel like there could be potential for the values to ‘leak’ if used this way and it seems like the artifact is not meant for that kind of use-case.
Is this advisable or not? I was trying to look through the documentation on an answer to this question, and I see we could set a quick expiry on the artifacts, but I worry about whether access could be gamed through other means to get at these values when you’re not supposed to.
If the answer is yes or no, it would be nice to have the documentation call this out explicitly.
I asked support this question.
For anyone that is wondering the same thing, here was the response:
Blockquote I do not recommend storing sensitive data in artifacts because they aren’t designed to be secure enclaves. Here’s documentation on storing and reading secrets with Hashicorp Vault and an alternative approach to storing secrets is using AWS Secrets Manager
We currently use Secrets Manager as mentioned in the original question. But its good to know this was not the design intent around artifacts.
Vault has encryption APIs designed to assist with securing data at rest.
I had the same problem, moving the AWS ECR Login credentials (which is a two step process) from one stage to another…
There is one container image with the AWS CLI which fetches the temporary login credentials for ECR and another where our container build is happening and which should push the container to the ECR Registry with the fetched credentials…
I just used openssl to encrypt the artifacts with a long password stored in a protected variable:
aws ecr get-login-password > registry-login
openssl enc -aes-256-cbc -in registry-login -out registry-login.enc -pbkdf2 -k $ENCRYPTION_PASSWORD
stage where the image is pushed
openssl enc -d -aes-256-cbc -in registry-login.enc -out registry-login -pbkdf2 -k $ENCRYPTION_PASSWORD
cat registry-login | docker login --username AWS --password-stdin 123456789123.dkr.ecr.eu-north-1.amazonaws.com
ENCRYPTION_PASSWORD is an protected CI/CD variable with like 32 random alphanumeric characters…
The build artifact can be read by other roles, but it contains only garbage / encrypted data, as someone without maintainer access to the repo can´t read the protected variable.