VxRail – Secure Boot and Attestation
- Ed Spaenij
- Apr 22, 2021
- 3 min read
Security is a key focus these days. For the security conscious customers, you can even configure your VxRail nodes so that upon booting up, they will verify the components that are involved in the boot process, to ensure that they are not tampered with. This post explains the Secure Boot process and how this is handled by VxRail.
Overview
A secure boot process verifies the components that are involved in that boot process. This is also called host attestation and is based on the UEFI boot process, VMware vSphere and the Trusted Platform Module (TPM) chip. This chip stores some digital certificates and TPM2.0 is supported since VxRail 4.7 (which uses vSphere 6.7).
The attestation tells us that the node has booted with Secure Boot enabled and it has only used signed code in the process. The gif image below shows a good overview of the secure boot process:
There is a good bit of documentation already out there that goes into further detail (see References), but the main thing to keep in mind is that in the BIOS you can:
Configure the properties for secure boot
Enable or Disable that secure boot process with a switch
Below table shows the expected outcome of the above settings:
You can see in the table, that an attestation alarm is not necessarily something to be alarmed about. In the case of the a misconfiguration or the switch being set to Disabled, an alarm will show, but the server will still boot and is just informing you that it is configured for Secure Boot, but something is not configured right.
Attestation Alarm
The alarm will be shown at all levels in the vCenter UI, for example:
The alarms for the cluster are also visible in the vSAN > Monitor > Security overview:
It won’t provide a cause, just the alarm notification. In case of a misconfiguration, you should be able to resolve this in the BIOS. If the BIOS was actually configured correctly, then the host wouldn’t have booted at all, and the console of the node would be showing a PSOD (purple screen of death). In that case an unsigned VIB may have been installed recently (and the PSOD will tell you the name of that VIB) or some lower level component (see the VMware gif image earlier in this post) was indeed tampered with!
BIOS Settings
There is a number of BIOS settings that are involved in the secure boot configuration. This is an overview of the relevant properties (shown on a Dell VxRail P570F node):
In the above items, the Secure Boot switch has been highlighted. Sometimes it is required to disable the Secure Boot, to enable maintenance or Lifecycle Management (LCM) to be performed. This will require the node to be rebooted before and after the operation. That is ok for one or two servers, but if you have more servers to do, then this becomes a very laborious and time-consuming process!
Enter VxRail…
A VxRail cluster may contain from 2 to many nodes. For VxRail systems on PowerEdge platforms running VxRail 4.7.2xx (and above) with secure boot enabled, upgrades to VxRail 4.7.410 (and above, including 7.0.x) do not need to have secure boot manually disabled/re-enabled before and after an LCM upgrade. The upgrade will execute while keeping secure boot enabled on the host. However, users must ensure that no unsigned VIBs are on the node, to prevent adverse effects during a host boot.
Conclusion
In a reality where security is becoming more and more a core component of primary importance, Secure Boot can be one of your trusted defense partners. Having VxRail clusters will ensure you will be properly supported if you do chose to use this capability.
References
VMware vSphere 7.0 Security Guide, UEFI Secure Boot for ESXi Hosts
VMware vSphere Blog, Security (Mike Foley’s posts)
Read more from Ed Spaenij on his blog: Virtual Ed
Comments