-
Notifications
You must be signed in to change notification settings - Fork 135
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
feat: add containerd-image-verifier-sigstore extension #597
base: main
Are you sure you want to change the base?
Conversation
fbd7fd9
to
ea1c078
Compare
## Usage | ||
|
||
```yaml | ||
machine: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say to put these files as part of extension, so adding this extension enables it. ClusterImagePolicy
can be an extension config (though /etc/containers/sigstore
needs to be an allowed extension path. possibly create a Talos discussion first)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@frezbo, thank you for taking a look!
I would say to put these files as part of extension, so adding this extension enables it
That's valid, though in Talos' current state, Kubernetes will fail to come up due to several images not being signed and even after that were resolved their workloads won't run without modifying this policy to include their expected keys or OIDC ID/issuer, see:
talosctl images default | xargs -I{} sh -c 'echo {}; cosign verify --certificate-oidc-issuer-regexp='.*' --certificate-identity-regexp='.*' -o text {}' sh
ClusterImagePolicy can be an extension config (though /etc/containers/sigstore needs to be an allowed extension path
as in something like this?
apiVersion: v1alpha1
kind: ExtensionServiceConfig
name: sigstore-policy-tester
configFiles:
- content: |
apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
name: system
spec:
images:
- glob: "**"
authorities:
- keyless:
url: https://fulcio.sigstore.dev
identities:
- issuer: https://accounts.google.com
subject: k8s-infra-gcr-promoter@k8s-artifacts-prod.iam.gserviceaccount.com
ctlog:
url: https://rekor.sigstore.dev
- keyless:
identities:
- issuer: https://accounts.google.com
subjectRegExp: "@siderolabs\.com$"
mountPath: /usr/local/etc/containers/sigstore/policy.yaml # The mount path of the extension service config file.
# The environment for the extension service.
environment:
- CONTAINERD_IMAGE_VERIFIER_SIGSTORE_POLICY_PATH=/usr/local/etc/containers/sigstore/policy.yaml
possibly create a Talos discussion first
I'll create one now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ea1c078
to
0a6e49f
Compare
Testing locally building and running with roughly the following
Then for the config, using a patch like so machine:
env:
CONTAINERD_IMAGE_VERIFIER_SIGSTORE_POLICY_PATH: /var/local/etc/containers/sigstore/policy.yaml
files:
- content: |
[plugins]
[plugins."io.containerd.image-verifier.v1.bindir"]
bin_dir = "/usr/local/bin/containerd-image-verifier"
max_verifiers = 10
per_verifier_timeout = "10s"
path: /etc/cri/conf.d/20-customization.part
op: create
- content: |
apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
name: system
spec:
images:
- glob: "**"
authorities:
- keyless:
url: https://fulcio.sigstore.dev
identities:
- issuer: https://accounts.google.com
subject: k8s-infra-gcr-promoter@k8s-artifacts-prod.iam.gserviceaccount.com
ctlog:
url: https://rekor.sigstore.dev
- keyless:
identities:
- issuer: https://accounts.google.com
subjectRegExp: "@siderolabs\.com$"
path: /var/local/etc/containers/sigstore/policy.yaml
op: create booting up a VM and generating config like so
validating the environment with
so far, I can't see that there's any affect from the config. Diving on debugging |
logs should appear like the following: https://github.com/containerd/containerd/blob/main/pkg/imageverifier/bindir/bindir.go#L58 I see nothing relevant under the containerd logs
except that the plugin has loaded
the containerd config looks as expected
the program is executable
|
check the |
I wonder if we can avoid global env's |
I don't quite like the name of the extensions, it should probably be around image-verifier naming, or the fact that it's a plugin. I'm not personally excited about the imager verifier API in containerd (of course it has nothing to do with this change), but I see the need to have such verification. |
files: | ||
- content: | | ||
[plugins] | ||
[plugins."io.containerd.image-verifier.v1.bindir"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also would like to check how this plugs in into the image pull process, there are multiple paths in the CRI/Talos itself before we declare this as a production solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the docs (https://github.com/containerd/containerd/blob/main/docs/image-verification.md#image-pull-judgement), it won't pull an image unless it passes the checks in the bindir
Return an exit code of 0 to allow the image to be pulled and any other exit code to block the image from being pulled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that containerd doesn't pull images ;)
In fact, they have Transfer API which is only used by ctr
, and direct pull, when the actual pull process happens outside of containerd. This API is being used by CRI & Talos. So image verification might be pulled into CRI, but it I doubt it covers all paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to https://youtu.be/fDDSg2NVwO4?t=322, containerd 2.1 will resolve this.
In any case, the functionality of image verification is what I'd like and it doesn't have to be this way. That said, there's work along this path to achieve this functionality
This is fair. What do you think about containerd-imageverifier-sigstore? |
The only logs for cri that are relevant are
The value can be overridden via an ldflag on build. I'll update it. |
7df0880
to
a0ef75e
Compare
To enable verifying of every container image run through containerd
a0ef75e
to
3066da4
Compare
To enable verifying of every container image run in containerd using Sigstore.
containerd has an ImageVerifier plugin which allows images to be allowed or denied depending on whether they return 0 or 1.
Most of the images delivered through Talos are signed, though problematically some are not.
Using a ClusterImagePolicy (from https://github.com/sigstore/policy-controller), at a system level, things can be defined for allow or deny.