OpenShift running Windows 11 and 2022 virtual machines
Here in this blog, we will learn about OpenShift running windows 11 and 2022 virtual machines.
Setting up the cluster to accommodate an ongoing vTPM
OpenShift Virtualization must generate a Persistent Volume Claim (PVC) to support the persistent storage of secrets in a virtual machine’s vTPM. The HyperConverged custom resource, usually named “kubevirt-hyperconverged” in the “openshift-cnv” namespace, needs to be configured with the storage class that offers vTPM state. To enable VMs using a persistent vTPM to use live migration, the storage class needs to be of the “Filesystem” type (FS) and support the “ReadWriteMany” access mode (RWX). Below is an illustration of the parameter from a cluster that uses Red Hat OpenShift Data Foundation:
Adding persistence to a VM
Because of a virtual machine’s spec.template.spec structure, changing the VM YAML to set the vTPM to persistent is also straightforward, albeit it requires going further up the hierarchy. The TPM setting is located under
You can add “persistent: true” under “tpm” to force the vTPM to use persistent storage:
You can make changes to the virtual machine while it’s running, but they won’t take effect until OpenShift Virtualization stops and restarts it. Include this parameter before launching the virtual machine (VM) for optimal outcomes.
Look for the PVC to confirm that the TPM is still in place. The virtual machine “win11-broken-cow” in this instance has a persistent TPM:
With regard to the vTPM feature, there are two significant warnings. Initially, for the duration that the virtual machine (VM) is running on, a non-persistent vTPM will store and return encryption keys. This covers restarts of the guest operating system. Thus, choosing to “Run BitLocker system check” during the drive encryption wizard’s process is insufficient when using BitLocker Drive Encryption for a Windows virtual machine. The issue arises when you shut down or migrate the virtual machine (VM), which causes the virt-launcher Pod to stop. As a result, you could encrypt a virtual machine’s disk and then instantly lose access to it the next time the machine restarts. In this situation, saving a copy of the recovery key would be the only way for Windows to force the user to recover the disk.
The second warning is that, as of the writing of this article, there is no way to take a snapshot of the vTPM PVC, so having a persistent vTPM prevents you from taking a snapshot of the virtual machine. This means that virtual machines (VMs) with persistent vTPMs cannot be backed up online. The feature, which is planned for OpenShift 4.17, is being tracked in CNV-32718.
proving tenacity in a Windows 11 virtual machine
Clone the Windows 11 template to start a new virtual machine (VM) with a base image of Windows 11. Create a base image using these instructions if one doesn’t already exist: OpenShift Pipelines for managing virtual machines. Change the VM’s YAML as indicated above to add “persistent: true” under “tpm:”. Verify that the selected VM has a “persistent-state-for-” PVC after the VM has booted up.
BitLocker Drive Encryption may now be used to encrypt the C: drive. If you use the wizard to begin the encryption process, select the option to print the recovery key to a PDF. OpenShift Virtualization does not currently offer the ability to attach a drive in a manner that Windows recognizes as removable, and if you select neither option, the wizard will not proceed. Joining an Active Directory domain with the BitLocker Key Recovery service configured is an additional recovery option, but this is outside the purview of this article and is still insufficient to trigger the wizard to proceed.
Shut down the virtual machine from OpenShift Virtualization to test the key persistence after the encryption process is finished. (Simply rebooting the operating system from within will cause the OS to restart in the virtual launcher pod that it was previously running in; thus, this is not a reliable way to test persistence.)
Conclusion
OpenShift Virtualization’s persistent vTPM feature makes compliant workloads that demand encryption at rest possible. In addition, there has been discussion about whether non-persisted vTPM should fail to save keys, and work is planned to enable snapshotting of the persistent storage to enable backup of encrypted virtual machines.