secret environment variables

[hholst80]

I think this really must be supported. I am almost sure I saw this somewhere too. Experimental feature?

I could not find the word "experimental" mentioned here https://github.com/moby/buildkit/tree/master/frontend/dockerfile/docs/syntax.md
so maybe I am not looking in the right place for this feature, if it already exists?

RUN --mount=type=secret,id=foo,env=FOO echo the secret is $FOO but do not tell anyone

[jedevc]

The syntax for secret mounts are here - using secrets as env variables like you describe isn't supported.

You can work around this by doing something like:

RUN --mount=type=secret,id=foo FOO="$(cat /run/secrets/foo)" echo the secret is $FOO but do not tell anyone

[jedevc]

RUN mounts as a concept do what they say on the tin - they mount secrets as files into that RUN command, extending that syntax to do something that doesn't create additional mount points could be a confusing place to attach this kind of functionality - that said, I'm not quite sure what the "right" place is.

If you can come up with a descriptive use case, and some potential syntax/semantics ideas, then a proposal issue would be the right place to try and discuss a potential implementation 🎉

[hholst80]

I guess one could just use build arguments for it and call it a day. I just thought from how K8s uses secrets and that they can be consumed either as files or as environment variables that it would make sense to have both routes available also in Dockerfiles.

[hholst80]

Earthly syntax is as follows (example from actual use case to export a mongoDB collection):

RUN --secret MONGODB_URI=+secrets/MONGODB_URI mongoexport -q "{\"site\": \"$SITE\"}" -c invoices -o export.jsonl --limit=100 "$MONGODB_URI"

[jedevc]

I guess one could just use build arguments for it and call it a day

I'd be careful with that approach - if the command that includes the ARG is included in a stage that makes up the final image, then the secret will make it into the image (and even if it's not, it might be placed into the cache if using mode=max on your cache).

[jedevc]

@tonistiigi @crazy-max do you have any thoughts on whether we'd want to add new syntax to support this use case?