31

You have 3 methods to get secrets to an app inside a docker container. The first 2 involve docker configuration. The last one is to have your apps directly fetch secrets from a secret store. 1 - Environment variables According to "The 12 Factor App" guide, secrets are merely config, and they should always be set in the environment. You could set your ...


5

Well, from a security point of view, it's never bad to give people less information. But, as long as you have sensible security policies in AWS, there is no reason that an arn has to be considered secret. For example, if you know the arn of the role I use to access s3 from my EC2 instances, you can't do anything with that information unless I give you ...


3

Do not store your state in anything besides remote backend. Even if you store it in a remote backend the secrets will appear in a plain text again, this is an ongoing Terraform limitation. In our case we are using AWS S3 backend ( although we have multi cloud environments ), we've got those key benefits out of the box: Encryption in transit and at rest. ...


1

By coincidence, I have found a possible solution via Github Secrets.


1

Developers or even admins of your GitHub repository wouldn't be able to see secrets configured there by default. Even if you debug GitHub Actions workflows and accidentally log secrets, GitHub would mark them with ***. So the only attack vector I can think of is highly deliberate and it would require modifying GitHub Actions workflow code and egressing the ...


1

My choice would be design B. It's true that the availability of the Vault would be crucial, but Jenkins' availability would similarly be crucial in design A. So from this perspective the decision would normally be driven by the comparison of the two availability figures, if available. Based on its functionality I suspect that Jenkins is likely to be a more ...


1

I'm not familiar with teamcity, but you can : add a config folder in your repo, and inside this repo create three files (staging.yml, preprod.yml, prod.yml). on each file you will write down variables specific to each environment, and apply them within pipeline. For secrets, it's cautious to handle that manually or better use Vault. To not throw on error ...


1

I was a little confused by the OP question and follow up, so answering about GitHub access to jenkinsfile-based pipeline jobs: Credentials stored in Jenkins can be available to all users with rights to create jobs. Use a GitHub deployment key for your repo. Yes you need a key for every repo. This does require a user in Github, of course, but there is nothing ...


1

There is another option only using pipe: docker run -d -i --name $n alpine sh -c 'read A; echo "[$A]"; exec some-server' docker exec -i $n sh -c 'cat > /proc/1/fd/0' <<< _a_secret_ First, create the docker daemon with -i, the command read A will hang waiting for the input from /proc/1/fd/0; Then run the second docker command, reading the secret ...


Only top voted, non community-wiki answers of a minimum length are eligible