openstack/nova
Code Issues Proposed changes
nova/doc/source/admin/emulated-tpm.rst
Stephen Finucane f4c249c692 docs: Document UEFI secure boot feature 
Introduce two new guides on UEFI and Secure Boot. In addition, update
the flavors guide to document the secure boot feature (though this doc
should really be removed in near term in favour of the auto-generated
docs, as noted inline).

Note that this change includes our first use of the ':nova:extra-spec:'
cross-reference role and highlights a small bug in that implementation.
This is resolved.

Blueprint: allow-secure-boot-for-qemu-kvm-guests
Change-Id: I4eb370b87ba8d0403c8c0ef038a909313a48d1d6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2021-03-12 17:42:02 +00:00

4.1 KiB
Raw Blame History

Emulated Trusted Platform Module (vTPM)

22.0.0 (Victoria)

Starting in the 22.0.0 (Victoria) release, Nova supports adding an emulated virtual Trusted Platform Module (vTPM) to guests.

Enabling vTPM

The following are required on each compute host wishing to support the vTPM feature:

  • Currently vTPM is only supported when using the libvirt compute driver with a :oslo.configlibvirt.virt_type of kvm or qemu.
  • A key manager service, such as barbican, must be configured to store secrets used to encrypt the virtual device files at rest.
  • QEMU version >= 2.11 (>= 2.12 is recommended)
  • Libvirt version >= 5.6.0
  • The swtpm binary and associated libraries.
  • Set the :oslo.configlibvirt.swtpm_enabled config option to True. This will enable support for both TPM version 1.2 and 2.0.

With the above requirements satisfied, verify vTPM 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 SECURITY_TPM
| COMPUTE_SECURITY_TPM_1_2 |
| COMPUTE_SECURITY_TPM_2_0 |

Configuring a flavor or image

A vTPM can be requested on a server via flavor extra_specs <vtpm-flavor> or image metadata properties.

Flavor extra_specs Image metadata Description
hw:tpm_version hw_tpm_version Specify the TPM version, 1.2 or 2.0. Required if requesting a vTPM.
hw:tpm_model hw_tpm_model Specify the TPM model, tpm-tis (the default) or tpm-crb (only valid with version 2.0.

Scheduling will fail if flavor and image supply conflicting values, or if model tpm-crb is requested with version 1.2.

Upon successful boot, the server should see a TPM device such as /dev/tpm0 which can be used in the same manner as a hardware TPM.

Limitations

  • Only server operations performed by the server owner are supported, as the user's credentials are required to unlock the virtual device files on the host. Thus the admin may need to decide whether to grant the user additional policy roles; if not, those operations are effectively disabled.
  • Live migration, evacuation, shelving and rescuing of servers with vTPMs is not currently supported.

Security

With a hardware TPM, the root of trust is a secret known only to the TPM user. In contrast, an emulated TPM comprises a file on disk which the libvirt daemon must be able to present to the guest. At rest, this file is encrypted using a passphrase stored in a key manager service. The passphrase in the key manager is associated with the credentials of the owner of the server (the user who initially created it). The passphrase is retrieved and used by libvirt to unlock the emulated TPM data any time the server is booted.

Although the above mechanism uses a libvirt secret that is both private (can't be displayed via the libvirt API or virsh) and ephemeral (exists only in memory, never on disk), it is theoretically possible for a sufficiently privileged user to retrieve the secret and/or vTPM data from memory.

A full analysis and discussion of security issues related to emulated TPM is beyond the scope of this document.

References