Design / flow for reference values

[travier]

Short summary of a discussion about the planned design for managing reference values in the operator.

The goal:

• Do not manage the reference values directly
• Store the values for the valid container images instead
• Re-computed as needed when the list of valid container images change

• Container image for the OS will have the PCR value in a LABEL (org.coreos.pcrs or something else, to be determined)

• https://github.com/confidential-clusters/compute-pcrs/blob/main/test-fixtures/quay.io_fedora_fedora-coreos_42.20250705.3.0/all-pcrs.json

• CRD to store for each image seen in the cluster:

  • image sha256sum / tag
  • Date first seen
  • PCR values (i.e. the label from the container above)

• Use Rust OCI crate or skopeo to fetch the label

• Watch CVO for new container versions & get the PCR values

  • https://github.com/openshift/cluster-version-operator

• Ask the library for the PCR value combination:

  • Code does not exist yet in the library
  • Pass all the container image PCR values & parts to the library to get the final reference values
  • PCR4: Add a cli/lib verb to get the hashes for shim & grub/systemd-boot from a container image compute-pcrs#21

• Inject those values in the trustee server

• Container pull flow is a fallback:

  • Compute PCRs #12

[travier]

Instead of using a LABEL for the PCR/parts values, we might use a file in the last layer of the container image as this would be easier to add to the build process: https://github.com/openshift/os/blob/63e9aa4008eb65a02a2d70c9c086cbd8e18e149f/Containerfile#L12 (would call compute-pcrs there)

This is not ready either so we can start with the LABEL first and we'll see how things goes later.

[alicefr]

@Jakob-Naucke as TODO, could we convert this description in a design document. It will be good keep track of our design decision and having a document describing this. A bit like #5