OCP wants to support Cosign / Sigstore in which the signatures for the releases will lie in the same registry repository. This spike studies the work that needs to be done on the cluster-version operator side or identify CVO work or other in-cluster work which has a dependency on other teams. It is unrelated to the Cincinnati-side work tracked in OTA-1267, which has a different release cycle.

We have a SigstoreImageVerification feature-gate and the plan is to be tech-preview in 4.17 and GA in 4.18. We're planning on using that existing feature gate in CVO work, although it would be possible to request a CVO-specific feature-gate if folks wanted to tune things at that level (e.g. node-team Sigstore work, but not CVO-side Sigstore work).

This work is orthogonal to the SignatureStores feature-gate and ClusterVersion spec.signatureStores property. That was tech-preview via OTA-946, and OTA-1118 is up to try to get it GA soon, possibly in 4.17, so it needs to have its own feature-gate and we cannot recycle that gate for this Sigstore epic.

Definition of Done: 

• Study how CVO will work with the new signature verification and how we can maintain the same UX that we have today.
• Create additional spikes/ stories for Cosign work.

Notes

OCPNODE-2231 and related node-team work might allow a CRI-O level policy that only accepts quay.io/openshift-release-dev/ocp-release release images (only in the openshift-cluster-version namespace? Or maybe that would also need OCPNODE-2253?) with accepted Sigstore signatures. This would be a departure from the current signature-verification process, where the outgoing CVO looks for a sufficiently trusted signature before bumping the CVO Deployment to hand off to the incoming release image, but there aren't further signature checks against that image after that. With a CRI-O policy, there would presumably be new signature checks whenever a new pod comes up (e.g. because the CVO is getting drained off one node and rescheduled to another for node maintenance). It's not clear how things like spec.desiredUpdate.force and status.history[].verified would fit into that world. I'm personally in favor of getting rid of force, because only Red-Hat-internal CI/QE should be playing with unsigned releases, but config.openshift.io/v1 is a tier 1 API, so we can deprecate those properties, but not remove them until OpenShift 5. Although there may be room to pivot the force implementation to "if the user sets this, remove the openshift-cluster-version Sigstore policy and never put it back; the cluster is now tainted forever" or similar without breaking the current API commitments.