Add support for --secret from buildx

[NakulK48]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Now that the extraOptions field is gone, there is no way of mounting a secret into the docker build, which is the recommended way of making use of secret keys when building.

https://docs.docker.com/engine/reference/commandline/buildx_build/#secret

I imagine supporting the full extraOptions is infeasible because of the move away from the docker CLI, but it would be helpful to have this available as a top-level field.

Affected area/feature

[guineveresaenger]

Thank you for filing this feature request!
We expected to see feature requests for some of the former extraOptions, and this is helping us learn which ones folks are actively using. We agree this is a good feature to support and will be working on an implementation soon.

[mike-chen-samsung]

EDIT: The comment below is outdated. We can securely add secrets to build args with version 4.4.2. It's not ideal though so supporting the --secrets flag is still very much desired.

Would like to add that doing something like this results in an error, so I don't think it's even possible to use v4 of this package to securely build images that require secrets. Or can someone point out a workaround?

build: {
  args: {
    NPM_TOKEN: secret(process.env.NPM_TOKEN!),

panic: interface conversion: interface {} is *resource.Secret, not resource.PropertyMap

[Jomik]

This seems like a pretty big caveat.
Can we expect to get this fixed so that we can properly build images that depend on private/secret resources?

[ShedPlant]

I already migrated to pulumi-docker 4 and realised I now can't use --secret at build time 😞 .

[ShedPlant]

@mike-chen-samsung can you please explain your workaround and its limitations?

Is there any chance of this being worked on in 2024?

Currently:

• my docker images need AWS CodeArtifact credentials to download libraries
• the credentials are copied into the docker image for the purpose of downloading the libraries
• the credentials are temporary for the developer or the CI run
• therefore the next CI run uses different credentials
• the docker cache is invalidated
• builds are less secure and slower to build than I would like

[mike-chen-samsung]

@ShedPlant my workaround is the same as what you're doing - we must copy the creds into the docker image which invalidates cache

[ascrookes]

Just adding a +1 that my team would also benefit from this feature. It is blocking us from using pulumi-docker. We have a similar workflow as @ShedPlant of needing to install from CodeArtifact as part of a build step and mounting the secret is the most secure way to go about that.

[blampe]

Hi folks, we just released a new Docker Build provider focused exclusively on building images with buildx/BuildKit. It provides --secret functionality out of the box, and we recommend you use it for building images going forward. Please take a look and give us feedback!

The repository is here; our blog announcement is here; and finally API docs are here along with examples of how to migrate your existing Image resources to dockerbuild.Image.

We won't be able to add this functionality in this provider for a number of reasons, so I'm closing this as wont-fix.

[ShedPlant]

Very exciting, thanks @blampe !