cosign + connaisseur - image with multiple cosign signatures to be verified before deployment

[tommyreilly]

Hi,

I'm new to this community so welcome any feedback and your patience if this is obvious. I just can't find relevant information or, ideally, an example.

A use case I want to test is to use cosign to sign an individual image multiple times with different keys. This can be done using the annotation argument to cosign sign. The use case is that in a CI->CD flow, there may be several stages along the path that individuals (or automation) might sign the image and each individual/automation stage would use their own private key to sign the image. For example, "vulnerability scan pass" = signature A, "QA pass" = signature B.

When the image is to be deployed to k8s, I would want connaisseur to confirm that the image contains both signature A and signature B. My understanding is that if a validator does not specify a trust_root in a validator, the single key listed in the default section would be verified. If a trust_root is defined in the policy, that single key listed in that matching section would be used. In either situation, there is only one single "key" field and no way to list multiple keys to be validated.

I see in the 2.0 Release, there is a reference to multi-key support but I'm unsure this means one and the same:

#151

If anyone could point me at any detail if this is supported with cosign/connaisseur with any detail I can follow up with, that would be very much appreciated.

Thanks

Tommy

[xopham]

Welcome @tommyreilly 👋 I like the use-case and think that is a very valid scenario.
Currently, Connaisseur does not support validating a single container image against multiple signatures via Cosign. This is, however, possible for the Notary v1 integration by enforcing delegations. In my opinion, delegations would be the most suitable way to integrate multiple signers for a single organization. While this is planned for Cosign, I have not noticed it to be implemented yet (see e.g. here or here).
I believe the annotation argument itself will only allow to add additional information that could be used to determine compliance with a policy. That is also something we are considering at the moment, but would require some sort of policy language to handle such information.
All of that being said, I would think that it should not be a big problem to simply verify an image against multiple keys defined for a validator. I am just not certain how to best expose that in the values.yaml. But let's assume, we'd offer to configure multiple trust roots in the image policy like:

- pattern: "docker.io/my-app/*:*"
  validator: my-validator
  with:
    trust_roots: ["vulnerability-scanner","qa-scanner"]

That would suffice for your use-case, right?

[xopham]

we could also widen this and add a required key to enforce some signatures or a threshold key to enforce a minimum of the listed roots 🤔

[tommyreilly]

Thanks @xopham for the quick reply. Yes, I like the suggestion of listing "trust_roots" instead of a single "trust_root" and then, as you say, identify if all or a minimum threshold are to be validated before deployment. It would meet the use case I describe.

Tommy

[xopham]

Neat. Am checking at the same time with Sigstore team whether there is a more direct way of doing so. But will pick this up and see if we can make it a feature in the next release...

[xopham]

tracking in #375

[xopham]

@tommyreilly the feature has been released after a looooong lead period 😉
you can find the docs here: https://sse-secure-systems.github.io/connaisseur/v2.5.0/validators/sigstore_cosign/#multi-signature-verification

Feel free to share your thoughts on the implementation 🚀