Verify base image signatures #356
Comments
|
I'd propose a similar two-release strategy to things we've done previously (e.g. requiring
|
|
I don't think there are enough signed base images in the wild yet to justify failing closed. A big scary warning sgtm though. Since we control the default and the default is signed, I do think it's safe to fail closed if we detect distroless isn't signed. |
|
@imjasonh Yeah 2 doesn't have to be the next release, but we should indicate in our scary warning that this is the direction we intend to head. We can always wake up smarter and walk that back, but the more people we can scare into taking action the better IMO |
|
To pontificate a bit. At least for me, While the breaking nature of this sort of against the idea of back-compatibility, I think the north star we want to remain compatible with is that we leave folks with containers that are as good as we can possibly produce given the evolution of best practices over time. I wonder if it would be worth including a bit about that as a sort of "mission statement" or "philosophy" for the tool in the main README.md? Sort of like we added the principles section to GGCR.
|
|
This applies similarly to: #357 |
|
Taking a stab at the latter two points: .ko.yaml: verifySignatures:
"alpine:1.23":
- publicKey: https://some.url/path/to/key.pub
annotations:
key: value
another: value2If any image is based on The default distroless base image has an assumed Users can configure other signatures that need to be verified for distroless, or any base image they use. Q: how should ephemeral OIDC keys be configured to be verified? If all base images involved in an invocation of wdyt? |
When `COSIGN_EXPERIMENTAL=true`, this will verify base images, and sign produced images using the KEYLESS flow. Fixes: ko-build#357 Fixes: ko-build#356
When `COSIGN_EXPERIMENTAL=true`, this will verify base images, and sign produced images using the KEYLESS flow. Fixes: ko-build#357 Fixes: ko-build#356
When `COSIGN_EXPERIMENTAL=true`, this will verify base images, and sign produced images using the KEYLESS flow. Fixes: ko-build#357 Fixes: ko-build#356
This change enables folks to start verifying their base images are signed against Fulcio by specifying `COSIGN_EXPERIMENTAL=true`, which will ensure each digest we intend to base an image on is verified. Unless `COSIGN_EXPERIMENTAL=true` is enabled, this change will have no effect. When `COSIGN_EXPERIMENTAL=true` is enabled, this change will verify base image digests, and emit a `WARNING:` when they are not signed (the `gcr.io/distroless` images are now signed!). When `COSIGN_EXPERIMENTAL=true` is enabled *AND* `--strict` is passed, then failure to verify a base image digest will fail the `ko` command. Related: ko-build#356
This change enables folks to start verifying their base images are signed against Fulcio by specifying `COSIGN_EXPERIMENTAL=true`, which will ensure each digest we intend to base an image on is verified. Unless `COSIGN_EXPERIMENTAL=true` is enabled, this change will have no effect. When `COSIGN_EXPERIMENTAL=true` is enabled, this change will verify base image digests, and emit a `WARNING:` when they are not signed (the `gcr.io/distroless` images are now signed!). When `COSIGN_EXPERIMENTAL=true` is enabled *AND* `--strict` is passed, then failure to verify a base image digest will fail the `ko` command. Related: ko-build#356
This change enables folks to start verifying their base images are signed against Fulcio by specifying `COSIGN_EXPERIMENTAL=true`, which will ensure each digest we intend to base an image on is verified. Unless `COSIGN_EXPERIMENTAL=true` is enabled, this change will have no effect. When `COSIGN_EXPERIMENTAL=true` is enabled, this change will verify base image digests, and emit a `WARNING:` when they are not signed (the `gcr.io/distroless` images are now signed!). When `COSIGN_EXPERIMENTAL=true` is enabled *AND* `--strict` is passed, then failure to verify a base image digest will fail the `ko` command. Related: ko-build#356
This change enables folks to start verifying their base images are signed against Fulcio by specifying `COSIGN_EXPERIMENTAL=true`, which will ensure each digest we intend to base an image on is verified. Unless `COSIGN_EXPERIMENTAL=true` is enabled, this change will have no effect. When `COSIGN_EXPERIMENTAL=true` is enabled, this change will verify base image digests, and emit a `WARNING:` when they are not signed (the `gcr.io/distroless` images are now signed!). When `COSIGN_EXPERIMENTAL=true` is enabled *AND* `--strict` is passed, then failure to verify a base image digest will fail the `ko` command. Related: ko-build#356
This change enables folks to start verifying their base images are signed against Fulcio by specifying `COSIGN_EXPERIMENTAL=true`, which will ensure each digest we intend to base an image on is verified. Unless `COSIGN_EXPERIMENTAL=true` is enabled, this change will have no effect. When `COSIGN_EXPERIMENTAL=true` is enabled, this change will verify base image digests, and emit a `WARNING:` when they are not signed (the `gcr.io/distroless` images are now signed!). When `COSIGN_EXPERIMENTAL=true` is enabled *AND* `--strict` is passed, then failure to verify a base image digest will fail the `ko` command. Related: ko-build#356
|
Revisiting this and adding a few thoughts after mulling this over a bit this morning. I think that rather than inventing our own ~API for verification, we should (similar to the Go releaser precedent) align around the I think there are a few key elements of configuration:
For For
This is significantly more capable that what you can easily do via
As a total strawperson proposal for this: verification:
no-match-policy: ...
policies:
- data: # inline policy
- url: # URL for a policy
- path: # Path to policy (support directories as well, like kubectl/ko -f)I think we should default this to something like: verification:
no-match-policy: warn
policies:
# a default policy covering our default base image (cgr.dev/chainguard/static*)
- data: ...
# Users can put CIPs/Secrets/TrustRoots under .ko/ (alongside .ko.yaml)
- path: .ko/Folks can get the current behavior with: verification:
# Allow uncovered images
no-match-policy: allow
# Specify no policies
policies: [] |
馃巵 This implements the very basics from my recent comment on ko-build#356. This still needs a bunch of work, but some playing with it and `go run` seem to demonstrate what I'd hope for. Things I'd like to do still: - Add validation that warns/errors if aspects of CIP irrelevant outside K8s are used (e.g. `match:`, `includeSpec:`), - Expand unit test coverage significantly, - Move `pkg/policy` upstream to `sigstore/policy-controller` to facilitate using this in other projects with similar ease (e.g. kaniko, buildpacks, ...) /kind feature
馃巵 This implements the very basics from my recent comment on ko-build#356. This still needs a bunch of work, but some playing with it and `go run` seem to demonstrate what I'd hope for. Things I'd like to do still: - Add validation that warns/errors if aspects of CIP irrelevant outside K8s are used (e.g. `match:`, `includeSpec:`), - Move `pkg/policy` upstream to `sigstore/policy-controller` to facilitate using this in other projects with similar ease (e.g. kaniko, buildpacks, ...) /kind feature
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This change factors a new small library `./pkg/policy` which is intended to streamline incorporating CIP validation into downstream tooling. For a (much) more verbose explanation see [here](ko-build/ko#356 (comment)), but the general idea behind this is to allow CIP's to gate consumption of images in other contexts, for example the base images in build tools such as `ko` or `kaniko`. The idea is to enable the tool providers to bake-in default policies for default base images, and optionally expose configuration to let users write policies to authorize base images prior to consumption. For example, I might write the following `.ko.yaml`: ```yaml verification: noMatchPolicy: deny policies: - data: | # inline policy - url: https://github.com/foo/bar/blobs/main/POLICY.yaml ``` With this library, it is likely <100 LoC to add base image policy verification to `ko`, and significantly simplifies our own `policy-tester` which has spaghetti code replicating some of this functionality. /kind feature Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
馃巵 This implements the very basics from my recent comment on ko-build#356. This still needs the upstream changes to land in a release, but illustrates how the integration will work. /kind feature
馃巵 This implements the very basics from my recent comment on ko-build#356. This still needs the upstream changes to land in a release, but illustrates how the integration will work. /kind feature
馃巵 This implements the very basics from my recent comment on ko-build#356. This still needs the upstream changes to land in a release, but illustrates how the integration will work. /kind feature
If
kois instructed to build an image based on another image, it would be nice to verify signatures on those base images.It just so happens the default base image, distroless, is signed. 馃帀
signing(edit) verifying the default distroless base image?cc @dlorenc
The text was updated successfully, but these errors were encountered: