At VMware we talk a lot about intrinsic security, which is the idea that security in a vSphere environment is baked in to the product at a deep level, not sprinkled on as an afterthought. Security is a huge focus of vSphere 7, even though when we talk about the new features it’s usually about certificate management improvements, vSGX, Identity Federation, and vSphere Trust Authority. All of the massive improvements to patching and upgrades, via vSphere Lifecycle Manager and Update Planner, are security features, too. If you cannot patch you can’t secure your environment from vulnerabilities that are discovered, and operational issues like bugs and driver issues (theoretically speaking, of course). 🙂 Operational issues affect availability, which is directly related to security, and it is all tied back to risk.
One of the ways you see vSphere 7 improving intrinsic security is by allowing vSphere Admins to manage deeper into the infrastructure itself. You see Lifecycle Manager now able to work together with tools like Dell EMC OpenManage Integration for VMware vCenter and HPE iLO Amplifier to manage server firmware as part of the remediation cycles. This is a huge deal because there are vulnerabilities in server & management controllers, too, and those are not fixed by simply updating ESXi. We need to make sure the hardware gets updated, too, so that it is a solid and safe foundation for us to build our infrastructures on.
Foundations of Trust
vSphere Trust Authority (vTA) is a tool to help ensure that our infrastructure is safe & secure, and to ensure that if its security is ever in question we act to repair it. To understand vTA we need to look back at vSphere 6.7, which introduced support for Trusted Platform Module (TPM) 2.0 and the host attestation process. A TPM is an inexpensive component ($20 to $40 US) that can be installed inside servers manufactured in the last 10 years or so. They’re often overlooked when ordering servers, so you may not have them, but they are modular and can be added after a server is deployed (though it’s much easier if you order them preinstalled – a tip for your next hardware order).
TPMs do three things:
First, a TPM serves as a cryptographic processor, and can generate cryptographic keys as well as random numbers. A TPM is connected over a serial bus inside the server, and when I say “serial” I mean less Universal Serial Bus (USB) and more “1990s modem speeds.” Truth is, most cryptographic operations are done by the main CPUs now, because those CPUs have very fast cryptographic functions (which is why technologies like VM Encryption and vSAN Encryption have very low overhead). Nevertheless, modem speeds are just fine for storing and retrieving keys and certificates and the like, which are all very small. The TPM random number generator can also be very helpful in jumpstarting, or “seeding,” the random number generators in CPUs and operating systems that run on bare metal, like hypervisors.
Second, a TPM can store cryptographic materials, like keys, certificates, and signatures. It has techniques called “binding” and “sealing” that help control how the secrets it stores can be retrieved. Furthermore, to prevent people from physically stealing a TPM and accessing the secrets, TPMs are cryptographically bound to the server you first enable them on. Do not buy any off eBay or try to recycle them from older systems (for fun search eBay for “TPM server” and you will see all sorts of them!).
Last, a TPM can help us determine if a system’s integrity is intact by doing something called “attestation.” The TPM can measure and store security information, and then summarize it in a way that is very cryptographically strong. If a server has UEFI Secure Boot and its TPM enabled, vCenter Server can collect these security measurements and determine if the system booted with authentic software, and in a configuration we trust. That is attestation, and you can see it in the vSphere Client’s “Security” section of the Monitor tab:
vSphere 6.7’s attestation is view-only, though. Beyond an alarm when there is a problem there are not really any repercussions for failing attestation. That means that a secure workload, such as one using VM Encryption to protect its data on disk, could potentially be moved by DRS back on to a questionable host. It also means that if vCenter Server, which handles all the encryption keys for a cluster, is running inside a cluster the encryption keys might be vulnerable. Last, we cannot encrypt vCenter Server, either, because there is a dependency loop.
vSphere Trust Authority
This is where vSphere Trust Authority comes in. vTA establishes its own management cluster, which serves as a hardware root of trust. This cluster is a very secure, heavily scrutinized, small cluster outside of the normal vSphere clusters in an environment. Ideally that cluster is separate from all other clusters and has a very small number of admins. The hosts that comprise this cluster run ESXi and can be very small machines since they likely will not be running any workloads. In lieu of a separate cluster, an existing management cluster can also serve as the vTA root of trust, making it easy to get started.
Once the vTA management cluster is established it handles two big tasks. First, it takes over the distribution of the encryption keys from the Key Management Servers (KMS). This means that vCenter Server no longer is in the critical path for those keys, which also means that we can encrypt vCenter Server to protect it. Second, vTA handles the attestation of other hosts. Because vTA handles the encryption keys, if a host fails attestation vTA will withhold the keys from it. This prevents secure workloads from moving to that host until the problem can be resolved. That is exactly what we want, since we do not want our secrets being given to potentially untrustworthy servers.
In Conclusion
vSphere Trust Authority is a new and very foundational technology right now, helping us build trust in our hardware and software configurations at deeper levels. At first glance it might look like vSphere Trust Authority is adding complexity, with a separate cluster and additional configuration work. For some folks that is true. However, security-oriented customers with larger deployments will find that this has the very real potential to simplify operations in their environments. The vTA management cluster can be used to attest thousands of hosts and clusters, so the cost and complexity of that cluster is offset by the lower risk and higher trust that vTA brings to their entire enterprise.
We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.
At VMware we talk a lot about intrinsic security, which is the idea that security in a vSphere environment is baked in to the product at a deep level, not sprinkled on as an afterthought. Security is a huge focus of vSphere 7, even though when we talk about the new features it’s usually about certificate management improvements, vSGX, Identity Federation, and vSphere Trust Authority. All of the massive improvements to patching and upgrades, via vSphere Lifecycle Manager and Update Planner, are security features, too. If you cannot patch you can’t secure your environment from vulnerabilities that are discovered, and operational issues like bugs and driver issues (theoretically speaking, of course). 🙂 Operational issues affect availability, which is directly related to security, and it is all tied back to risk.
vSphere Trust Authority (vTA) is a tool to help ensure that our infrastructure is safe & secure, and to ensure that if its security is ever in question we act to repair it. To understand vTA we need to look back at vSphere 6.7, which introduced support for Trusted Platform Module (TPM) 2.0 and the host attestation process. A TPM is an inexpensive component ($20 to $40 US) that can be installed inside servers manufactured in the last 10 years or so. They’re often overlooked when ordering servers, so you may not have them, but they are modular and can be added after a server is deployed (though it’s much easier if you order them preinstalled – a tip for your next hardware order).
