RFE: dockerfile secret

[kfox1111]

I've got a few dockerfiles that are staring to use/need the secret support in newer docker versions. This allows you to inject things like rpm signing keys which otherwise would be leaked out, or need nasty hacks to fetch.

See the secret support examples here:
https://docs.docker.com/develop/develop-images/build_enhancements/

Could support for these options be added to buildah please?

[TomSweeneyRedHat]

We'll certainly consider it. Thanks for the request and pointers.

[rhatdan]

@QiWang19 PTAL

[QiWang19]

Docker support this with docker build --secret and uses buildkit for RUN --mount in the Dockerfile. Is it possible for buildah to implement this functionality? @TomSweeneyRedHat @nalind @rhatdan

[rhatdan]

Is buildah bud -v SECRETPATH:DESTPATH ...
Enough to satisfy this requirement?

[kfox1111]

Its a slightly different api then that. I'm using it here:
https://github.com/kfox1111/hubbuildtools/blob/master/hubhookhelpers/build#L33
and here:
https://github.com/pnnl-miscscripts/miscscripts/blob/master/containers/rpms-containerd/Dockerfile

Half of the mount info is on the command line. The other half is in the Dockerfile at the RUN

While you could have just one -v option and that would solve the ability to inject things into the build, it wouldn't allow buildah bud to be compatible with existing Dockerfiles. It also wouldn't allow the secrets to be exposed only to some of the containers in a multistage environment.

[rhatdan]

Strange looking at this command line.
docker build --no-cache --progress=plain --secret "id=gpg,src=$GPGKEY" -t tmp$$:1 . "$@"
I don't see --progress or --secret documented?
$ docker --version
Docker version 19.03.5, build 633a0ea838

In man pages or in docker build --help?

[rhatdan]

Also I have never seen this syntax before

RUN --mount=type=secret,
...

[kfox1111]

Its documented here:
https://docs.docker.com/develop/develop-images/build_enhancements/
Under the section:
New Docker Build secret information

The --progress=plain is also documented on that page.

[rhatdan]

Great, but it is not in a released/supported Docker yet, correct?

[kfox1111]

Its been a while since I looked closely. It was experimental when I wrote the code initially. But I think its released/supported now:
https://github.com/moby/buildkit/tree/docker-19.03/frontend/dockerfile/instructions has reference to secret support.
Looks like as of 19.03 at least, you still need to do:
export DOCKER_BUILDKIT=1
before docker build.
docker build --help then does look to have the options.

[rhatdan]

Cool, interested in porting the code to buildah?

[kfox1111]

Too much to do, and too little time right now. Sorry. :/

[rhatdan]

No problem, hopefully we can get someone to work on it.

[emonty]

FWIW - I ran in to a similar issue trying to use podman build on a Dockerfile that is also using

# syntax=docker/dockerfile:1.1.3-experimental

specifically:

RUN --mount=source=/output,target=/output,from=builder \
  /output/install-from-bindep

Which should mount the /output directory from the builder stage. Obviously in this case it could just be

COPY --from=builder /output/ /output
RUN /output/install-from-bindep

which is, in fact, the code we were looking at replacing (don't need that output dir in any of the final image layers, mounting seems nicer.

[rhatdan]

Intersted in opening a PR to add this feature?

[rhatdan]

@QiWang19 PTAL

[rhatdan]

@ashley-cui Since you have taken over secrets, here is an issue for you.

[rhatdan]

A couple of use cases where this can be used as well.

[skorhone]

This feature would be extremely useful for anyone who is using Dockerfiles to define builds and installing packages from private repositories.

Currently the only option for those that use Dockerfiles is to use build args. If build uses short lived tokens and multiple stages, it's reasonably safe. It's just extremely complicated and use of short lived tokens in build args kills caching.

[rhatdan]

Can's you also do this with build volumes?

buildah bud -v /sourc/secret:/dest/secret ...

[skorhone]

I missed that option. I could and for most parts it would be the same as using docker's --secret argument. It's not the same, because docker doesn't mention copying to container.

I know that following goes well beyond original request. I have a feeling that this way of passing secrets is overly complicated. I'd like to see a way of passing secrets as environment variables. Consider how intuitive it would be, if we had something like --secret-build-arg FOO. Which would make buildah read FOO from build environment and pass it to build container. To prevent secret from leaking and to make caching work properly, buildah would need to replace secret with a static string such as "SECRET" in command history.

[skorhone]

"For example, if you supply /foo as the host path, Buildah copies the contents of /foo to the container filesystem on the host and bind mounts that into the container."

I think this is a bit confusing. I initially thought this means that copied files will become part of final image. Container filesystem translates in my head to filesystem inside the container.

Also, if this is recommended way of handling secrets, documentation should recommend using overlay option for secrets. If you're building in e.g. kubernetes and secrets location isn't a physical disk, you probably want to avoid making copies of secrets on a filesystem

[rhatdan]

@ashley-cui is working on a --secrets flag to do some of the stuff that you want. But if you need it now, these are the things we have.

[rhatdan]

Secrets patch was just merged. @ashley-cui Does the secrets patch work with podman build?

[ashley-cui]

@rhatdan I don't think so, I only wired it up to create/run so far

[rhatdan]

Ok we need to get this wired into buid, if possible. Probably need to make buildah work with it first.

[missedone]

i'm looking for this feature as well, it's the blocker for us migrating from buildkit to buildah

[lcbm]

At our project, we're also interested in this.

We build using Docker locally and built with Kaniko before we ship, in our CI/CD pipeline. However, we now need to use buildkit for the --secret feature in order to to pass secret information (sensitive credentials) to be used in the Dockerfile for building images (more specifically, to download our private packages) in a safe way that will not end up stored in the final image. This is not supported by Kaniko (amongst other things) and we are finally making an effort to migrate tools.

It'd be great if Buildah supported this -- we would gladly migrate to it 😄

I'll leave the Dockerfile here for reference 👇

Dockerfile

# syntax=docker/dockerfile:1.2
FROM python:3.8-slim

# ...

COPY requirements_private.txt .
RUN --mount=type=secret,id=secrets \
  export $(cat /run/secrets/secrets) && \
  pip install --no-cache-dir --quiet --no-deps -r requirements_private.txt

# ...

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@ashley-cui have you been able to look into this?

[ashley-cui]

@rhatdan looked into it a little bit, but keep getting distracted by mac work so have't really gotten anywhere.

[skorhone]

@ashley-cui You wouldn't have time to add environment variable based source? The reason for this request is that most CI services pass secrets as environment variables. Creating a temporary file just doesn't feel right (or safe)

I noted that current implementation creates a copy of secret file. It seems like easiest interim solution would be to create copy using contents of environment variable as source. This wouldn't get us rid of temporary files completely, but it would be a step into right direction.

The next step would be adding --mount=type=secret-env,id=secret to expose secret as environment variable instead of a file. This would allow command running inside build container to use secret without having it stored on disk

[TomSweeneyRedHat]

Based on the last comment, I'm going to reopen this. @ashley-cui @skorhone I'll let the two of you decide if a new issue should be spun up instead.

[ashley-cui]

Sounds like a good idea, I'm working on this in podman-land right now, so I'll get to this after that.

[ashley-cui]

I think the env variable source should be a different issue, since I think this issue should only encompass the --mount=type=secret, as Docker does this. Docker has other --mount types too, and they should also be addressed in other issues. If you would like, @skorhone, please open a new issue with environment secrets, and I can possibly take a look later.