- VMware Enhanced Authentication Plug-in—Why do we still need it with vSphere 7.0? - Fri, Jul 3 2020
- VMware VCSA 7 backup - Fri, Jun 26 2020
- vSphere 7.0 unsupported CPUs and ESXi 7.0 hardware requirements - Fri, Jun 12 2020
The management hosts are pretty much "locked down," which means that a very small group of people can access those hosts, where the workload hosts (green) can be accessed by a larger group. The management cluster runs management software, such as vCenter Server or other monitoring solutions.
The architecture basically relies on the principle of least privilege, whereby the admin should really only have privileges to do what needs to be done. A separation of roles is essential when planning security.
VMware is trying to work toward a better security model, and the introduction of vTA is the first step. vTA represents the foundation to which VMware will add more functions in future releases. In this release, VMware is building the base block of the architecture.
The main vSphere Trust Authority (vTA) features ^
VMware vTA creates a hardware root of trust using a separate ESXi host cluster: This might be a problem for certain clients since, as you can see, the management cluster is used only for management, not for running workloads. Explain this to a client who is on a budget, and who does not have the money to spend on three hosts that do not directly run his production environment. The trusted hosts will be running the corporate workloads, which are encrypted and cannot be moved to hosts that are not trusted.
Key manager and attestation requirement: The VMware Key Management Server was introduced in vSphere 6.5 to allow encryption of VMs. You set up a trusted connection between the vCenter Server and a Key Management Server (KMS). The vCenter Server can then retrieve keys from the KMS as needed. The vSphere Trust Authority will enable setting that attestation can be a requirement for access to encryption keys. This will further reinforce the security, to prevent a potential intruder from getting the encryption keys to decrypt your encrypted VMs and gain access to the company's data. The Key Manager only talks to trusted hosts, not to the vCenter Server, as in previous releases.
vSphere 6.7 and its attestations were "view only," so there were no repercussions for failing. The secure workloads could still run on untrusted hosts. vTA and vSphere 7 allow the Key Manager to talk to trusted hosts instead of the vCenter Server (which is a VM).
Can encrypt workload vCenter server instances: In 6.5 and 6.7, you cannot encrypt the vCenter Server VM as there are many dependencies. vSphere 7.0 will be able to encrypt vCenter Server instances.
Principle of Least Privilege: You can restrict access such that a very small group of admins can access the trusted hosts. Again, separation of roles and privileges is important. The "green" hosts in the diagram above can be accessed and managed by a wider group of admins, whereas access to "blue" hosts remains restricted.
Trusted Platform Module (TPM 2.0): This is a $20 trusted platform module chip that can be ordered from your hardware manufacturer and which is cryptographically signed and attached to the host when you first plug it in. (Note: don't buy these on eBay since they are usually used and are worthless.)
The VMware vSphere Trust Authority is a set of features that will reinforce your organization's security by leveraging a trusted platform module that is integrated into the hardware. There is also a set of features that enable running vCenter within a completely secured environment while leveraging encryption for the vCenter Server itself.
The possibility of separating access to the management cluster and the workload cluster reduces the audit scope and risk, which wasn't really possible with the previous vSphere design.
I think the coming vSphere 7.0 release is quite exciting. So far, this release has only been announced, and there is no exact release date, but I would not be surprised if the release happens just a couple of weeks after this announcement.