c76c72cfe0
Cleanup doc/code ref of HyperV driver. Change-Id: I6cd8fb90829e040bfd356ff6b1c41aa9a1c906d2
3.5 KiB
Secure Boot
14.0.0 (Newton)
23.0.0 (Wallaby)
Added support for Secure Boot to the libvirt driver.
Nova supports configuring UEFI Secure Boot for guests. Secure Boot aims to ensure no unsigned kernel code runs on a machine.
Enabling Secure Boot
Currently the configuration of UEFI guest bootloaders is only
supported when using the libvirt compute driver with a :oslo.configlibvirt.virt_type of
kvm or qemu. In both cases, it requires the
guests also be configured with a UEFI bootloader <uefi>.
With these requirements satisfied, you can verify UEFI Secure Boot support by inspecting the traits on the compute node's resource provider:
$ COMPUTE_UUID=$(openstack resource provider list --name $HOST -f value -c uuid)
$ openstack resource provider trait list $COMPUTE_UUID | grep COMPUTE_SECURITY_UEFI_SECURE_BOOT
| COMPUTE_SECURITY_UEFI_SECURE_BOOT |Configuring a flavor or image
Configuring UEFI Secure Boot for guests varies depending on the
compute driver in use. In all cases, a UEFI guest bootloader <uefi> must be configured
for the guest but there are also additional requirements depending on
the compute driver in use.
Libvirt
As the name would suggest, UEFI Secure Boot requires that a UEFI
bootloader be configured for guests. When this is done, UEFI Secure Boot
support can be configured using the :novaos:secure_boot extra spec or equivalent image
metadata property. For example, to configure an image that meets both of
these requirements:
$ openstack image set \
--property hw_firmware_type=uefi \
--property os_secure_boot=required \
$IMAGENote
On x86_64 hosts, enabling secure boot also requires configuring use
of the Q35 machine type. This can be configured on a per-guest basis
using the hw_machine_type image metadata property or
automatically for all guests created on a host using the
:oslo.configlibvirt.hw_machine_type config option.
It is also possible to explicitly request that secure boot be disabled. This is the default behavior, so this request is typically useful when an admin wishes to explicitly prevent a user requesting secure boot by uploading their own image with relevant image properties. For example, to disable secure boot via the flavor:
$ openstack flavor set --property os:secure_boot=disabled $FLAVORFinally, it is possible to request that secure boot be enabled if the host supports it. This is only possible via the image metadata property. When this is requested, secure boot will only be enabled if the host supports this feature and the other constraints, namely that a UEFI guest bootloader is configured, are met. For example:
$ openstack image set --property os_secure_boot=optional $IMAGENote
If both the image metadata property and flavor extra spec are provided, they must match. If they do not, an error will be raised.