In some recent times I had to deal with Amazon AWS cli credentials inside Docker containers.
Everything sounds easy when you are in development. You may think of creating the config file by hand or pasting the IAM Account credentials in the CLI…
Sure that’s simple, but It is a different thing when you go to production.
Setting the credentials by hand is not an option anymore. Plus you need to be really careful not to leak anything into the VCS (Git)… Which is more common that what you would expect.
The way to go
We handle sensitive information in Docker Swarm (as well as other container managers like Kubernetes) with “SECRETS“
a secret is a blob of data, such as a password, SSH private key, SSL certificate, or another piece of data that should not be transmitted over a network or stored unencrypted in a Dockerfile or in your application’s source code. You can use Docker secrets to centrally manage this data and securely transmit it to only those containers that need access to it. Secrets are encrypted during transit and at rest in a Docker swarm. A given secret is only accessible to those services which have been granted explicit access to it, and only while those service tasks are running.
Docker docs: https://docs.docker.com/engine/swarm/secrets/
Creating a secret is pretty straight forward but using it in some other processes may get tricky.
NOTE: There are other alternatives, like storing the full config file as a secret and use the "target" property in docker/compose to point it to the AWS credentials path, but this option is less flexible and may not suit every project. Also there is a way for AWS cli to retrieve credentials from an external process, you can read more here: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html
The solution
For the requirements of our project, we wanted a way to store keys “standalone” to feed the to the Amazon AWS cli credentials file.
That means that in every secret we are just storing the key string, and not the full AWS config file.
This gives us more flexibility when using those secrets in other services/processes
What we came up with is this simple, jet effective, sh script. It runs on the image startup and grabs the content of those secrets putting them in the proper file.
Code at GitHub
Link to gist: https://gist.github.com/nesjett/06f10f4aadcc6a8012d0b5de9f3d3c7f
Conclusions
There are different approaches to this problem, this is just one of the options available.
This particular one allows our Sys Admins to manage everything from within web interfaces like Portainer and Rancher
