Compose: support cosign

[AkihiroSuda]

Depends on:

• nerdctl run: support --verify=cosign #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

[AkihiroSuda]

cc @developer-guy @Dentrax @ktock

[fahedouch]

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

[AkihiroSuda]

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

No, because a single YAML may have references to images signed with different keys.

[developer-guy]

sounds amazing @AkihiroSuda 🤩 when do we start implementing this 🚀

[Dentrax]

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

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]

[fahedouch]

@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

[junnplus]

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]

[developer-guy]

kindly ping ✌️

[Zheaoli]

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.

[developer-guy]

kindly ping @AkihiroSuda @Dentrax