Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker Image improvements to support container scanning #775

Open
isaac-pulumi opened this issue Oct 3, 2023 · 3 comments
Open

Docker Image improvements to support container scanning #775

isaac-pulumi opened this issue Oct 3, 2023 · 3 comments
Labels
kind/enhancement Improvements or new features

Comments

@isaac-pulumi
Copy link

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

@isaac-pulumi isaac-pulumi added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Oct 3, 2023
@mikhailshilkov
Copy link
Member

@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?

@mikhailshilkov mikhailshilkov removed the needs-triage Needs attention from the triage team label Oct 4, 2023
@blampe
Copy link
Contributor

blampe commented Nov 21, 2023

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

4 participants