Define the Margo application image and component signing strategy

[ajcraig]

Feature description

Goal: Define the application image and component signing strategy required in Margo.

This feature is critical in a Multi vendor ecosystem and will enable trust and authenticity between the participants.

Category

• Trust

Provide adequate technical acceptance criteria(s) associated with this feature below:

• Define how application components are signed within Margo
  • app package / Helm chart / compose packages
• Define how oci images are signed within Margo
• Define how WFMs and Devices are able to verify the signature during application deployment
• Define, if necessary, any Margo infrastructure required to enable this verification between vendors
• Describe how these signatures live on even if the end user replicates the artifacts to a local repository

Although not required, it is highly encouraged to provide feature use-cases below:

1. Enables end user to verify the authenticity of the Application from the supplier
2. Device to verify authenticity during deployment activities
3. Ensure artifacts have not been tampered with while moving through the margo enabled ecosystem.

Additional information

Discussions have taken place on this topic in various locations.

• https://discord.com/channels/1225812888854200382/1273314391609311294
• linked Issue from previous discussion

https://www.signstore.dev
https://github.com/sigstore/cosign
https://github.com/scitt-community

Notes from minimum scope definition exercise:

There are multiple ways OCI artifacts can be signed (Cosign, Notary V2, GPG, etc.), and each one works differently. If we do not specify a single approach, interoperability will be difficult to achieve on the device side because the device vendor will not know what approach to take to validate signatures.

[Silvanoc]

One of the motivations for using OCI technologies is that this is a resolved issue with that technology. Another Linux Foundation project comes to the rescue: Cosign

It has been already mentioned in the linked Discord conversation by a user that cannot be identified anymore.

With OCI signing all the workflows/use-cases mentioned by @phil-abb and @bnieuwborg can be covered, leaving the heavy-lifting for an established and widely used technology stack.

Why can they be covered?

• Having composition, each subcomponent can be signed by a different party.
  • Container images are frequently signed by whom built them, the app builder can validate those signatures before packaging the app.
  • App builders can sign their apps.
  • App consumers typically will trust the app providers and only validate that they've signed the apps being consumed. But they could even validate the container images.
• Validation is possible both on- and off-line. Cosign supports both approaches. Of course, all needed public keys need to be provisioned for the off-line approach.
• Signatures are content-dependent, meaning that it is possible to differentiate two different apps from the same signing authority.
• Cosign in its on-line setup using Fulcio provides some of the TUF features, what helps making the whole setup even more secure.

As mentioned in the Discord conversation too, SBOM & Co. are also part of the OCI ecosystem.

We have only one uncovered spot: desired state. Since we are not using an OCI format there, we need to take care of it there ourselves. It is not rocket-science, but we need to do it (right) and maintain it.