Docker Image improvements to support container scanning

[isaac-pulumi]

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

Currently the Docker provider performs image build and publish actions in a single step. The proposal is to enable an interim "test" step that would allow scanning before pushing the image to the users' designated registry.

Proposal

Any Pulumi program that builds a container image could be blocked from publishing a container by policy if the container image fails scanning. This would require modification of the Docker provider to insert an arbitrary scanning step between build and publish. A successful scan can be required via CrossGuard policy.

On a successful scan, the Pulumi Docker provider would digitally sign the container image to ensure the image isn’t altered and attest the scan was successfully completed. (And/Or) the signature could be saved in Pulumi Environments. Pulumi audit logs should show where scans were run, the scan results or if the scan was skipped where redundant to do so.

Affected area/feature

[mikhailshilkov]

@isaac-pulumi I wasn't able to reserve much time for this work item in M95, so a heads-up that we are not prepared to meet the short timelines that we discussed earlier.

@AaronFriel @guineveresaenger I release there were some previous discussions/prototypes here. Can we link all prior art on this topic from this issue?

[blampe]

@isaac-pulumi @AaronFriel @guineveresaenger do any of you have an idea of the API you'd like to see for something like this?

Since the provider exposes a skipPush option it seems intermediate steps can already happen via dependsOn relationships. In pseudocode something like

const build = new docker.Image(...) // skipPush: true

const scan = new local.Command(..., { dependsOn: [build] })

const push = new docker.Image(...) // push locally cached image with DOCKER_CONTENT_TRUST=1

the Pulumi Docker provider would digitally sign the container image to ensure the image isn’t altered and attest the scan was successfully completed.

If the above is reasonable, then I think the work here involves figuring out a way to give signing keys to the provider.

(We do similar signing in the Pulumi SaaS, but the signing step happens out of band because the provider doesn't have these keys.)

the signature could be saved in Pulumi Environments. Pulumi audit logs should show where scans were run, the scan results or if the scan was skipped where redundant to do so.

This sounds like you're asking for something with very tight integration with Pulumi Cloud, which is a lot more involved.

[AaronFriel]

I don't think we should use Image for the "push" action but I agree that in principle separating build and push is desirable.

I would push back on the deep integration with Pulumi Cloud as well - I think what would address the need is:

1. A separate resource for pushing a local image to a remote registry, which can run an optional check command - should be fairly similar to the Command provider, in that it only needs to run when the input image changes.
2. A policy as code example that enforces that:

• All Image resources have "skipPush: true"
• All PushImage resources have a particular command, e.g.: snyk scan.

I suspect the partner has tools to measure scanning success and failure, and of course from a Pulumi user perspective, scan failures are deployment failures.