CODEWITHSUNDEEP
dockerdocker-buildkit
redesaid
redesaid

Reputation: 83

Right way to use secret flag in docker buildkit

I am struggling with the same problem mentioned by Gavin on this question.

Specifically in with new docker build secret information

What is the right way to use it that feature?

Looking around on the internet I only found some variations of the same example in docker documentation mentioned above, which prints the secret on build time. Maybe I didn't fully understand the example, so please help me.

If there is no way to get the secret in build time an use in another part of a Dockerfile (e.g. an ARG variable or RUN command), when and how that new feature can be used to truly keep my secret safe and also do the work?

My go is to use this new feature in build time and also keep my secret information safe in case someone get my image file and execute a history on it.

For example, ff I have a Dockerfile like this:

FROM influxdb:2.0
ENV DOCKER_INFLUXDB_INIT_MODE=setup
ENV DOCKER_INFLUXDB_INIT_USERNAME=admin
ENV DOCKER_INFLUXDB_INIT_PASSWORD="mypassword"

How can I use that new feature mentioned in docker documentation to set my variable (DOCKER_INFLUXDB_INIT_PASSWORD), for example, in a way that it will not logged in image history?

Thanks in advance

Upvotes: 7

Views: 9858

Answers (1)

larsks
larsks

Reputation: 311712

How can I use that new feature mentioned in docker documentation to set my variable (DOCKER_INFLUXDB_INIT_PASSWORD), for example, in a way that it will not logged in image history?

It depends on whether you need the secret only at build time, or whether you actually want to use it at runtime. The latter situation is probably more common, and there's already a canonical solution:

If you want to keep DOCKER_INFLUXDB_INIT_PASSWORD out of your image history, just don't set it during the build process. Require it to be set a runtime, e.g., via the -e VAR=VALUE argument to docker run (or the --env-file option):

docker run -e DOCKER_INFLUXDB_INIT_PASSWORD=mypassword myimage

You could have an ENTRYPOINT script that checks for the variable at runtime and exits with a helpful error message if it's not set.

The official Docker images for things like MySQL and PostgreSQL work this way.

In contrast, a build secret is meant for secrets that are only required at build time. For example, let's say your build process needs to do something like this:

RUN curl -o /data/mydataset -u username:password \
  https://example.com/dataset

You'd like to share your Dockerfile and associated sources with other people, but you don't want to share your username and password. This is where build secrets come in. You would instead stick your authentication information in a file, and modify your Dockerfile to read that information from a secret:

RUN --mount=type=secret,id=mysecret \
  curl -o /data/mydataset -u $(cat /run/secrets/mysecret) \
  https://example.com/dataset

In this example, once we've copied the remote file into the image, we're done with the secret: we don't need it in order to run a container from the image; it was only required during the build process.

NB: The above assumes that you're providing the secret at build time as described in the documentation, so your build command might look something like:

DOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=mysecret.txt -t myimage .

Upvotes: 10

Related Questions