Epic Goal

Require OpenShift updates to use canonical pullspecs from quay.io/openshift-release-dev/ocp-release (for OCP) or quay.io/okd/scos-release (for OKD).

Why is this important?

As part of the gradual OpenPGP-to-Sigstore transition, we want to have update security in Sigstore that's at least as strong as the existing cluster-version operator OpenPGP security. Currently the cluster-version operator's OpenPGP/GPG trusts keys that are baked into the release payload, with separate keyrings trusted for [OCP expected for https://github.com/openshift/cluster-update-keys/blob/b3cae8f22b51d9062d0ceb6ac9cf2f7651b4ce8f/manifests.rhel/0000_90_cluster-update-keys_configmap.yaml#L6 and OKD. As we move towards Sigstore coverage, the openshift ClusterImagePolicy is new in 4.21 to establish the authenticity of OCP release images. But customers can add other (Cluster)ImagePolicies to establish the authenticity of other images using other signers, including signers not maintained by Red Hat. That's appropriate for covering user workloads. But this epic is tightening down OpenShift behavior to block signed-for-user-workload images from being used as update targets.

Scenarios

An external signer getting compromised and used to sign a malicious OpenShift release image may be unlikely, but could be possible, and we want to implement reasonable guards against that situation. With this Epic delivered, a cluster-admin requesting an update to example.com/my/openshift@sha256:... will have that request rejected (at least for standalone clusters, where the cluster-version operator has a chance to review update requests before accepting them). In order to support internal testing and other emergency use, the usual spec.desiredUpdate.force hammer will blast through the new guard and accept the update request.

Dependencies

The cluster-update-keys repository needs to code the expected registry/repository for OpenShift release images, so that it can select between OCP and OKD at build time. That GitHub repository has a limited approver set with staff engineers, at least one of whom will need to be involved in this effort to approve changes there.

Contributing Teams

• Development - OTA (cluster-version operator maintainers), Node (Sigstore-in-OpenShift integration leads)
• Documentation - OTA, Node
• QE - OTA
• PX - OTA, Node

Acceptance Criteria

Test coverage for standalone clusters, ensuring requests for updates to example.com/my/openshift@sha256:... are rejected based on the unexpected pullspec repository/registry, before any registry contact is initiated.

Drawbacks or Risk

Check OpenShift Update Service behavior to confirm that it serves canonical pullspecs, and that it does not use the local mirror registry in the advice it serves to local clusters. Even if OSUS correctly serves the canonical pullspecs, there may be customers who have been using local-mirror pullspecs instead of relying on their mirror config while using canonical pullspecs. If we are concerned about these risks, we could mitigate by warning in an initial implementation before stiffening the guard to blocking in a future release.

Done - Checklist

• CI Testing - Tests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)