nerdctl
nerdctl copied to clipboard
containerd
Compose: support cosign
Depends on:
- https://github.com/containerd/nerdctl/issues/611
Cosign support for nerdctl pull and nerdctl push is being added in #556 #606 (v0.15).
We should support cosign for nerdctl compose too.
Probably we should extend the Compose Spec with x-nerdctl- prefix. https://github.com/compose-spec/compose-spec/blob/master/spec.md#extension
YAML for verifying the image could be like this:
services:
foo:
image: bar
x-nerdctl-verify: cosign
x-nerdctl-cosign-key: /path/to/cosign.pub
But I'm not sure how the YAML should look like for signing the images with nerdctl compose push, as we will have to have two different properties for prv key and pub key.
Maybe like this:
services:
foo:
image: bar
x-nerdctl-verify: cosign
x-nerdctl-cosign-public-key: /path/to/cosign.pub
x-nerdctl-sign: cosign
x-nerdctl-cosign-private-key: /path/to/cosign.key
otherwise we don't have to set the configuration in the compose spec it can be supported by flags. sthg like nerdctl compose pull --verify=cosign --cosign-key=/path/to/key may be very useful too
otherwise we don't have to set the configuration in the compose spec it can be supported by flags. sthg like
nerdctl compose pull --verify=cosign --cosign-key=/path/to/keymay be very useful too
No, because a single YAML may have references to images signed with different keys.
otherwise we don't have to set the configuration in the compose spec it can be supported by flags. sthg like
nerdctl compose pull --verify=cosign --cosign-key=/path/to/keymay be very useful too
Passing --verify and --cosign-key flags would be a bit ambiguous from the UX perspective. It had better not to pass these flags, since what I understand here is like: "I signed an alternate compose file and trying to verify the file using cosign just before calling the pull command. If verification fails, skip the pull operation."
If we really want to pass variables by using flags, we probably find a way out how should we map the specified key for each image such as follows:
--verify=cosign --cosign-key=[IMAGE1:/path/to/key1] --cosign-key=[IMAGE2:/path/to/key2]
@AkihiroSuda @Dentrax
I do not really agree. When we do nerdctl compose pull --verify=cosign --cosign-key=/path/to/key , we are aware that we are targeting all services in the specs : verifying all images with same key
targeting specific service(image) will be sthg like this : nerdctl compose pull service1 --verify=cosign --cosign-key=/path/to/key.
having the cosign verification in the spec has a lot of advantages too. The major one is that this verification is easily reproductible
When we do nerdctl compose pull --verify=cosign --cosign-key=/path/to/key , we are aware that we are targeting all services in the specs : verifying all images with same key
I think in most cases, the signature keys of different images may be different, which cannot be controlled by the user.
Maybe we can map the specified key for different services.
--verify=cosign --cosign-key=[SERVICE1:/path/to/key1] --cosign-key=[SERVICE2:/path/to/key2]
I think maybe we can follow the following design.
services:
foo:
image: bar
x-nerdctl-verify: cosign
x-nerdctl-cosign-key: /path/to/cosign.pub
foo2:
image: bar
x-nerdctl-need-verify: true
codesign:
x-nerdctl-cosign-key: /path/to/cosign.pub
People can spec a global cosign key and decide which image would be verified and override the global key or not.
