Support building Dockerfiles that mount secrets as environment variables

[carles-garcia]

Feature request description

Since Dockerfile 1.10 the Docker Engine can mount secrets as environment variables specified in the RUN command.

https://docs.docker.com/build/buildkit/dockerfile-release-notes/#1100

https://docs.docker.com/reference/dockerfile/#example-mount-as-environment-variable

It would be useful for podman build to support it. It's already possible using podman run.

[rhatdan]

@flouthoc any chance you could look at this?

[flouthoc]

I'll take a look at this.

[github-actions[bot]]

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

[hdub-tech]

This works in podman and buildah. I recently submitted a PR to update the podman build documentation Examples to demonstrate how to use podman build with secrets in environment variables, and I am planning to submit a similar one for the buildah documentation. There is already an example on Issue #5808, with the clarification that it was just using the wrong case in the id field of the buildah command.

[LucasLundJensen]

@hdub-tech I think what is asked for here is the ability to use the env field when mounting the secret, not when adding the secret to the build through an environment variable.

Example from Docker's documentation

RUN --mount=type=secret,id=aws-key-id,env=AWS_ACCESS_KEY_ID

The env property today doesn't seem to exist for RUN. I am at least getting an error message: secret should have syntax id=id[,target=path,required=bool,mode=uint,uid=uint,gid=uint]

This would temporarily add the value of the secret as an Environment Variable.

[hdub-tech]

Ohhhh my apologies, I completely misunderstood that! That would be an awesome feature which I would absolutely utilize.

[juv]

Hi, it would be great to have this feature similar to docker. This will also make fixing anti-patterns like the "secrets used in arg or env" more easy for buildah/podman users as they can simply adapt the necessary changes based on the guides in the Docker documentation.

Now, one has to use something like this in a theoretical case :

RUN --mount=type=secret,id=SOME_SECRET \
    --mount=type=secret,id=ANOTHER_SECRET \
    SOME_SECRET=$(cat /run/secrets/SOME_SECRET) \
    && ANOTHER_SECRET=$(cat /run/secrets/ANOTHER_SECRET) \
    && mvn package

With this new feature instead, it will be a bit more readable and possibly less error-prone

RUN --mount=type=secret,id=SOME_SECRET,env=SOME_SECRET \
    --mount=type=secret,id=ANOTHER_SECRET,env=ANOTHER_SECRET \
    mvn package