Allow `--secret` flag to be set via an environment variable

[bentekkie]

Description

I would like to be able to set the --secret flag via an environment variable so that I can have some secrets always automatically specified for my docker build commands.

[thaJeztah]

This probably relates to buildx, which is the cli-plugin that's executed when running docker build

Let me transfer this ticket

[thaJeztah]

From a quick look, I wonder if this would be more something to handle through docker buildx bake (and a bakefile to set defaults to pass)

[bentekkie]

Ideally I would prefer this to work OOTB with docker build so that for example I could run an arbitrary script that might have docker build commands and have the secret provided to all of the builds.
I think this could also be implemented at the BuildKit instance level to have globally loaded secrets in the BuildKit instance but I think that is a much larger and more complicated change

[bentekkie]

Alternatively is there any way for a BuildKit frontend to add secrets to the secret store for a build session?
I know that retreiving the value of secrets in the frontend would be insecure but it would be handy if a frontend could inject secrets into the secret store. The usecase would be to inject files into RUN commands (like CA certificates) that one doesnt want to persist into the final image

[tonistiigi]

You can load secret value from env, but you still need to add flag for this loading to happen via --secret or Bake definition. I guess "auto-load" could be possible for some very specific env prefix but probably don't want these exception cases to confuse users.

so that for example I could run an arbitrary script that might have

Technically, we have automatic --load per builder that could maybe be extended to all properties (eg. for bake where there is already logic for merging definition). I think we need more use cases, though.

I know that retreiving the value of secrets in the frontend would be insecure but it would be handy if a frontend could inject secrets into the secret store.

This is also technically possible, but would need to understand use-case more. We do want secrets to be used "for secrets", not for some side effect that happens when loading secrets. Otherwise, it should probably be adding some new construct in buildkit.

[bentekkie]

For my usecase I was actually able to solve this with a wrapper around the runc binary that injected the required environment variables and secret files that I needed.
Ideally it would be nice if BuildKit had support for injecting instance wide secrets like this but for now this workaround works.