vSphere Trust Authority (vTA) is a new and very foundational technology right now. If you are a security-oriented customer with large deployments, you should look at this feature: … as said in Bob’s blog “this has the very real potential to simplify operations in their environments“.
Basically, vSphere Trust Authority (vTA) provides enhanced security by limiting your sensitive workloads to run only on a trusted infrastructure.
Likewise, did you know that Trust Authority is one (#3) of the 10 reasons why you should upgrade to vSphere 7 ?
As a start, I recommend to watch Bob Planker’s video to get a good introduction to Trust Authority in vSphere.
vSphere Trust Authority
vTA in vSphere 7 is a step forward for being able to enforce trustworthiness in hardware and software.
Accordingly, vTA provides enhanced security of your sensitive workloads in a way they run only on a trusted infrastructure. In other words, vTA allows you to take workloads to higher levels of trust, ones that have encryption enabled, specifically called VM encryption.
| Let’s see now some architectural considerations around implementing it and why it’s helpful. |
vSphere Trust Authority Architecture
Here is a simplified view of the architecture, where the vTA components are:
- Attestation Service
- attests the state of a remote ESXi host. Uses TPM 2.0 to establish a hardware root of trust, and verifies software measurements against a list of administrator approved ESX versions.
- Key Provider Service
- encapsulates one or more key servers and exposes Trusted Key Providers that can be specified when encrypting virtual machines.
In this schema we have:
- Trust Authority Cluster: Consists of ESXi hosts that run the Trust Authority Services.
- Key Servers: Store encryption keys that are used by vSphere to perform encryption operations. The key servers are external to vSphere Trust Authority.
- Trusted Cluster: Consists of ESXi Trusted Hosts, which have been remotely attested with a Trusted Platform Module (TPM) and that run encrypted workloads.
- Trust Authority Administrator
Administrator who is a member of the vCenter Server TrustedAdmins group, and configures the Trusted Infrastructure. The Trust Authority Administrator is not the same as the vSphere Administrator, it is a separate user. - VM Administrator
Administrator who has been granted privileges to manage the encrypted workload virtual machines on the Trusted Hosts.
How it works
vSphere Trust Authority (vTA) changes the way the KMS interacts with a vSphere cluster. It actually proxyes the KMS interactions through the vTA Management Cluster (as opposed to vCenter Server). Specifically, it does this to control access to the secrets, so that a host that is untrustworthy does not have access to secrets, and thus cannot run encrypted workloads anymore.
Your hosts need UEFI Secure Boot enabled and TPM 2.0 installed and enabled, since vTA determines trustworthiness through attestation service.
Overview how to configure vSphere Trust Authority
- Enable the Trust Authority Administrator
- Collect Information About Hosts You Want to Be Trusted (the Trusted Hosts) – That’s where you export the TPM 2.0 chip certificate, the ESXi image, and the vCenter Server principal information, from the ESXi hosts in the Trusted Cluster.
- Enable the Trusted State on the Trust Authority Cluster
- Import the Trusted Host Information to the Trust Authority Cluster
- Create the Key Provider on the Trust Authority Cluster
- Export the Trust Authority Cluster Information
- Import the Trust Authority Cluster Information to the Trusted Hosts
- Configure the Trusted Key Provider for Trusted Hosts
As a result, when the Trusted Infrastructure is configured, you can begin distributing encryption keys to your ESXi Trusted Hosts and perform cryptographic operations on them. Refer to Use Encryption in Your vSphere Environment for additional information.
Simply said: you can begin deploying encrypted VMs on the ESXi Trusted Hosts 🙂
| Additionally, it’s important to be aware that you cannot move an encrypted VM from a trusted to a non-trusted host. |
To conclude …
To summarize conceptually, the vSphere Trust Authority (vTA) introduces a foundational technology aimed at securing the SDDC against malicious attacks.
How? By extending the trustworthiness of a Trusted Computing Base to the entire organization’s compute infrastructure using remote attestation technologies and controlled conditional access to advanced cryptographic capabilities.
Finally, vSphere Trust Authority is an automated method of setting up and maintaining a secure infrastructure, with integrity protection. It does ensure that sensitive workloads only run on a hardware and software stack proven to be in verified good condition.
To go further, everything you need to know in technical details about vTA and how to implement is here.
Check-out our last posts:
- https://mysticmarvin.eu/dellemc-announced-the-futur-of-vxrail/
- https://mysticmarvin.eu/marvins-notes-from-the-field-vxrail-manager-connectivity/
- https://mysticmarvin.eu/vsphere-7-part-3-identity-federation/
- https://mysticmarvin.eu/vsphere-7-part-2-certificate-management/
- https://mysticmarvin.eu/introducing-2nd-version-vmwarecloud-on-dellemc/
- https://mysticmarvin.eu/vsphere-7-part-1-new-logic-for-vmotion/
- https://mysticmarvin.eu/vsphere-7-whats-new-in-a-nutshell/
- https://mysticmarvin.eu/vsan-best-practices-part-iii/
- https://mysticmarvin.eu/vxrail-7-software-released/
3 Replies to “vSphere 7 – Part 4: Trust Authority”