Quickstart of image signing and enable verification

[Xynnn007]

Change Log

• Added guide to sign an image with cosign.
• Added guide to configure policy.json to enable signature verification to specific image repository.
• Added guide to add cosign verification key and policy to Offline-Fs-KBC's resources.

[Xynnn007]

Hi @sameo @fitzthum @stevenhorsman could you give some suggestions about this? thanks!

[Xynnn007]

I think we have some work to do (maybe covered in confidential-containers/community#63) to help enable users to modify their guest images if required (such as when using offline_fs_kbc to test out features like signatures, encrypted images without remote attestation/on non-CC hardware) and some of this information will be great for this, but I'm not sure we are ready for it yet.

Thanks for you reply @stevenhorsman ! I've checked the link and I'm quite not sure about that. Are you referring that if we add new signatures, it is hard for a user to produce a new guest image which contains the signature?

If so, cosign does not need the image to be modified, because its signatures are stored in the registry where the image lies.

I need to go through this more closely and set-up the cosign, but at a high-leve I'm wondering if the quickstart.md isn't the correct place for the docs at the moment (maybe somewhere in image-rs, or a separate doc page?).

I think we are planning to split up the quickstart guide into several smaller files. It's already too long and too complicated. It would probably be a good idea to make this a separate file and just add a link to it in the guide.

Yes I agree with that. I also found that this doc is too long for me to start when editting this. Maybe we need to refactor this doc into more small docs and add a TOC doc? I'm not sure.

It might be good to document the kernel parameter that enables signature verification. I don't see that here.

Thanks for your suggestion @fitzthum ! I'll add them then.

[stevenhorsman]

Thanks for you reply @stevenhorsman ! I've checked the link and I'm quite not sure about that. Are you referring that if we add new signatures, it is hard for a user to produce a new guest image which contains the signature?

Yes - exactly this point that we don't have a good method for updating the guest image, which the link talks about adding for the sample (option 4), which we could re-use to modify the file. The good news is that with the extra kernel_params exposed in CoCo 0.2 this is becoming a lot easier and the agent-config.toml isn't required now.

If so, cosign does not need the image to be modified, because its signatures are stored in the registry where the image lies.

So my understanding (which might be wrong) is that with cosign you still need to provide the policy and cosign key via the get_resources endpoint. For remote attestation I think we now don't need to modify the image for this, but the doc made references to offline_fs_kbc, which means we need to modify the guest image to add the aa-offline_fs_kbc-resources.json in. I hope that helps clarify?

[Xynnn007]

So my understanding (which might be wrong) is that with cosign you still need to provide the policy and cosign key via the get_resources endpoint. For remote attestation I think we now don't need to modify the image for this, but the doc made references to offline_fs_kbc, which means we need to modify the guest image to add the aa-offline_fs_kbc-resources.json in. I hope that helps clarify?

Yes, know it well! Thanks for your clarification.

[Alex-Carter01]

Thank you for writing all of this out, I have found it incredibly helpful! I have been consulting it enough that I figured I should leave some fixes for typos and such.

[Xynnn007]

So my understanding (which might be wrong) is that with cosign you still need to provide the policy and cosign key via the get_resources endpoint. For remote attestation I think we now don't need to modify the image for this, but the doc made references to offline_fs_kbc, which means we need to modify the guest image to add the aa-offline_fs_kbc-resources.json in. I hope that helps clarify?

For this disadvantage, I think there may be still a way to avoid modifying guest image frequently.

• Use verdictd-eaa instead of offline-fs-kbc until we finally turn to generic KBS&CC-KBC.
• Use cosign instead of simple signing

cc @arronwy

[Xynnn007]

I've put a pr in image-rs for this. https://github.com/confidential-containers/image-rs/pull/87
When it passes, I will change this pr to a single link