Option C: At runtime on a single node, without Swarm Mode or other orchestration, you can mount the credentials as a read only volume. RUN -mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://.Īnd you build it with a command in 18.09 or newer like: DOCKER_BUILDKIT=1 docker build -t your_image -secret id=aws,src=$HOME/.aws/credentials. The resulting Dockerfile looks like: # syntax = docker/dockerfile:experimental That mount does not get written to the image layers, so you can access the secret during build without worrying it will be pushed to a public registry server. Option B: Also during build time, if you can use BuildKit which was released in 18.09, there are currently experimental features to allow the injection of secrets as a volume mount for a single RUN line. This secret is still in the image cache on the build server, so I tend to use this only as a last resort. You would add the secret to the initial stages of the build, use it there, and then copy the output of that stage without the secret to your release stage, and only push that release stage to the registry servers.
Option A: If you need this secret only during the build of your image, cannot use the secret before the build starts, and do not have access to BuildKit yet, then a multi-stage build is a best of the bad options. So what other options are there for secrets in Docker containers? Even if you delete the secret from one layer, the image can be disassembled with common Linux utilities like tar and the secret can be found from the step where it was first added to the image. In the image itself: images often get pushed to registries where many users have pull access, sometimes without any credentials required to pull the image. Once you start running things outside of the cloud, or have a different type of secret, there are two key places that I recommend against storing secrets:Įnvironment variables: when these are defined on a container, every process inside the container has access to them, they are visible via /proc, apps may dump their environment to stdout where it gets stored in the logs, and most importantly, they appear in clear text when you inspect the container.
#Sitesucker how to pass credentials plus
If you can do that, then add one more plus one to his answer and skip the rest of this. A lot has changed in Docker since this question was asked, so here's an attempt at an updated answer.įirst, specifically with AWS credentials on containers already running inside of the cloud, using IAM roles as Vor suggests is a really good option.
0 kommentar(er)
