The second phase of work needed from team MCO to support the confidential compute initiative requires implementing functionality for the following:

• Logic to filter config applications that are invalid in confidential clusters
• Logic to ensure MachineConfigs are only served to attested nodes
• Ensure rpm-ostree is not used for any confidential cluster operations (bootc only)
• Meet general GA criteria for bootc and confidential computing FeatureGates

The two main logic updates needed from this stage are adding functionality to filter out MachineConfigs referencing invalid config options in confidential clusters and ensuring that MachineConfigs are only applied to attested nodes. Both of these are likely to need a spike to understand the scope of work and implementation details.

At this point in the confidential compute initiative, we need to ensure that rpm-ostree is not used for any processes relevant to such clusters. This work will also likely require a spike to understand if there are any configuration changes that will be supported in confidential clusters that rely on rpm-ostree and refinement of any future stories, if needed.

The final set of work to complete for this phase is promoting the confidential computing and bootc FeatureGates to default. The bootc GA work will be completed as part of a bootc focused epic, so the only FeatureGate to track promoting to default for this work is the confidential compute feature gate created in MCO-2067. This will require the development of regression tests to prove component readiness and then allowing for the proper soak time to get the required pass rate to ultimately promote the FeatureGate. Tentatively, I’d propose the following as scenarios warranting regression tests:

• Invalid MachineConfigs should be blocked on application
• Confidential clusters should not use rpm-ostree for any processes
• MachineConfigs should only be served to attested nodes
  • Apply MachineConfig to attested node and check it works properly
  • Apply MachineConfig to invalid node and check it is properly blocked
• Open testing question: Is there a need for penetration testing or other security testing before confidential computing’s GA? Is there a need from the MCO to cover any such testing requirements?

This phase should ideally align with RHCOS’s plan of releasing confidential clusters in as GenerallyAvailable in Q2 of 2026, though both the MCO and RHCOS teams understand this timeline is improbable.