1. Proposed title of this feature request

In-cluster Prometheus for FIPS-ness

2. What is the nature and description of the request?

There should be a way for actors with access to in-cluster Thanos to run PromQL queries and learn if there are any FIPS-enabled MachineConfig(Pool)s.

3. Why does the customer need this? (List the business requirements here)

We have occasional bugs with FIPS, and eventually might have a regression that only impacts FIPS clusters. If FIPS-ness is known to the in-cluster Thanos, conditional update risks can declare those regressions to impacted clusters, helping to keep those customers safe and aware. And it would allow us to avoid bothering non-FIPS clusters with discussion of a FIPS-specific issue. Without in-cluster Thanos exposure (the current situation), we have to try and balance the noise of waving this in front of all clusters (FIPS or not) vs. the risk of not waving this in front of any clusters (even those about to update into the regression).

Besides FIPS regressions, there's similar interest in informing FIPS clusters that the next minor version (4.(y+1)) has not been FIPS-certified, as discussed here.  The same conditional update risk approach could be used to pass that information along to FIPS clusters.

4. List any affected packages or components.

The machine-config operator already exports metrics about MachineConfigPools, it just doesn't expose spec.fips for the rendered MachineConfig the pools are targeting.