Feature Overview (aka. Goal Summary)

OSD Customers want the ability to enable the UEFISecureBoot during installation to fulfill the correct ShieldVM GCP Policy constraints and not be disabled during (or after) the installation.

In some cases, customers have argued that GKE provides the Shielded VM functionality (tablestakes) and expect something similar from OpenShift. While, it can be seen as a box-ticking exercise, but this feature request has merit as it protects enterprise workloads from remote attacks, privilege escalation, and malicious insiders.

Background

• Shielded VMs are virtual machines (VMs) on Google Cloud hardened by a set of security controls that help defend against rootkits and bootkits. Using Shielded VMs helps protect enterprise workloads from threats like remote attacks, privilege escalation, and malicious insiders. They run firmware which is signed and verified using Google's Certificate Authority, ensuring that the instance's firmware is unmodified and establishing the root of trust for Secure Boot. 
• ShieldVM GCP policy (“constraints/compute.requireShieldedVm”) offers verifiable integrity of the Compute Engine VM instances, so customers can be confident that their instances haven't been compromised by boot- or kernel-level malware or rootkits. 

More details in XCMSTRAT-115.

Goals (aka. expected user outcomes)

Enable UEFISecureBoot for day 2 VMs (required by ShieldVM policy) in Hive for OSD/GCP.

Requirements (aka. Acceptance Criteria):

Openshift 4.13 introduced the GCP customization for enabling Shielded VMs. Placing this configuration in the install-config.yaml ensures that the initial workers and master nodes are deployed with the secureBoot setting. However, through manual testing it was found that this functionality alone will not be enough to satisfy the requirements for Openshift Dedicated clusters. OSD clusters are deployed with a set of infra nodes. These infra nodes are deployed via hive as a machine pool resource. From the perspective of the spoke cluster, these infra nodes constitute a day-2 machineset. These nodes are not created with the secure boot setting, because Hive does not currently have a way to specify this setting for its machine pools. Likewise, day-2 machine pools that are created will be missing the secure boot settings, as its machineset configuration will once again come from what is specified in its corresponding machine pool. The secureBoot setting must be consistent across all nodes. It is therefore necessary for CS to be able to specify to Hive that the secureBoot feature is being used via a property of the machine pool.

Versions needed: OpenShift 4.13+

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios. Initial completion during Refinement status.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope. Initial completion during Refinement status.

Background

Provide any additional context is needed to frame the feature. Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.