MCO should refuse upgrading FIPS clusters to operating systems not stamped as FIPS validated

[cgwalters]

Today we have this nice high level knob fips: true. However, for RHEL, only certain minor releases are certified.

I believe this is tracked in the OpenShift process that builds releases in an effectively manual way. But I think it'd be better if we:

• Provided some metadata in the OS stream that described that the content was FIPS certified; strawman: flag in /usr/lib/os-release that also gets exposed in the ostree commit metadata and the machine-os-content container metadata
• Teach the MCD to require this flag on the oscontainer before even pulling an OS update down if fips: true

The main goal here would be to avoid potential errors in the release stream - we simply could not accidentally publish an OS update that was not FIPS validated into an OCP release, because our CI would block it directly.

[yuqi-zhang]

I think this should be more of a CVO level feature. I was under the impression https://github.com/openshift/enhancements/blob/2cc2d9b331532c852878a7c793f3a754914c824e/enhancements/update/targeted-update-edge-blocking.md was the option we were looking at

[cgwalters]

Closing per private discussion

[sdodson]

The TL;DR on the private discussion is that outside of situations where Red Hat does not seek FIPs certification for a given RHEL version, like RHEL 8.3, the FIPS certification is largely de-coupled an OpenShift payload and thus machine-os-content. So when RHEL 8.4 and everything built atop 8.4 attains certification that covers previously released bits.

We do intend to inhibit clusters from upgrading into non FIPS certified versions, but at this time it will need to be a solution which exists outside of the shipped payload, most likely via Targeted Edge Blocking as @yuqi-zhang mentioned.