Security and Compliance in vSphere 7

Most organizations today are running their business-critical workloads in virtualized environments. There are many advantages to virtualizing your workloads from a management, performance, scalability, and high-availability standpoint. However, it also means you have many workloads on one physical host. This helps to underscore the fact that in virtualized environments, security is extremely important.

If a virtual host is compromised by an attacker, they have access to many workloads and not just a single physical server. In addition to security concerns, many organizations are bound by certain compliance regulations that mandate various security features and safeguards are in place.

VMware vSphere 7 represents the latest and greatest hypervisor from VMware that touts the latest capabilities and features from a security perspective. These new features help to both secure your business-critical data and also ensure regulatory compliance. Let’s take a look at the new security and compliance features that are found in vSphere 7.

New VMware vSphere 7 security features

VMware vSphere 7 contains many new security features that help to bolster the security of your virtual infrastructure across the board. What new security features are included in VMware vSphere 7?

• Virtualized Software Guard Extensions (vSGX)
• Improved Certificate Management
• vSphere Trust Authority (vTA)
• Identity Federation

Let’s see how each of these new security features help to bolster the overall security and compliance of your environment.

Virtualized Software Guard Extensions (vSGX)

Not long ago, Intel released a technology they call Software Guard Extensions (SGX). With SGX, applications can define private, vaulted areas of memory (aka secure enclaves) where the contents are protected and unable to be viewed by any process that exists outside of the enclave itself. Modern Intel CPUs that have this feature use the CPU to encrypt a certain area of memory. Then, the enclave is decrypted on the fly within the CPU for code and data running inside the secure enclave.

What types of data may be included inside the Software Guard Extensions area of memory? When you think about some of the most sensitive data, this would certainly include cryptographic keys or other information that is highly sensitive.

Using this approach, the CPU allows processes or data running inside the secure enclave to “spy upon” or examine other code or data in the secure enclave. All other outside processes are considered to be untrusted. This includes even the operating system or a hypervisor such as VMware ESXi.

In vSphere 7, VMware has included the ability for a virtual machine to take advantage of this new Intel-specific feature. The new security feature in vSphere 7 is called Virtual Software Guard Extensions (vSGX). With vSGX, VMware provides the ability for applications that are running inside a virtual machine to take advantage of the protected areas of memory made possible by the vSGX capabilities.

When you think about how many layers of infrastructure have access to application secrets in a traditional vSphere hypervisor environment, this includes many layers. The guest operating system is running inside of ESXi. ESXi is loaded on top of the physical hardware of the ESXi host. And the physical hardware has visibility into ESXi.

This means that everything from the guest operating system to the ESXi hypervisor has access and can “see” inside of the application secrets as these are being passed around. However, with vSGX, admins can flag on the feature in the virtual hardware of the virtual machine and protect their application secrets running inside a virtual machine from any other layer having access to sensitive information. Once the feature is flagged on, the other layers of the infrastructure stack can no longer see inside the application secret.

Requirements of vSGX

There are various requirements for enabling the vSGX feature in vSphere 7. What are those?

CPU Requirements

• The vSGX feature is an Intel processor feature that is only available in “Coffee Lake” CPUs or later

Virtual Machine requirements

• Virtual machine must be running EFI firmware
• The VM Hardware version must be at hardware version 17 or higher

vCenter and ESXi Requirements

• Must be running vCenter Server 7.0 or higher
• Must be running ESXi 7.0 or higher

Supported Guest Operating Systems

• Linux
• Windows Server 2016 (64-bit) and later
• Windows 10 (64-bit) and later

Limitations of vSGX

There are a few limitations to be aware of when enabling the vSGX feature in your vSphere 7 environment. These include unsupported operations in your vSphere environment:

• vMotion and DRS operations are not supported
• Virtual machine suspend and resume operations are not supported
• You cannot create a snapshot on a VM if the snapshot includes memory
• Fault tolerance is not supported
• VMware AppDefense guest integrity foundation is not compatible

Enabling vSGX in vSphere 7

The vSGX feature in vSphere 7 is easily enabled on an existing VM or new VM. This is a property of the virtual machine settings when created/edited in the vSphere Client. As you can see below, this new feature can be seen under the Virtual Hardware section of the customize hardware step of creating a virtual machine.

Enabling the vSGX feature in the properties of a virtual machine in vSphere 7 (image courtesy of VMware)

Improved Certificate Management

Certificate management, as in most environments, is critical to the security of your vSphere infrastructure. With VMware vSphere 7, VMware has completely revisited the certificate management architecture and tooling. All of the new features and changes have helped to make certificate management in vSphere 7 much easier, which in turn, helps to bolster security.

Certificate management improvements include the following:

• Solution certificates are deprecated and a simpler approach has been adopted to connect other products like vRealize Operations
• New RESTful APIs have been added to handle vCenter Server certificates
• VMware has simplified the overall number of certificates needed in vCenter and ESXi
• New certificate management modes

Easier solution integration from certificate standpoint

One of the first things to note with vSphere 7 certificates is the easier solution integration from a certificate standpoint that allow other products to integrate with vCenter. Products such as vRealize Operations, vRealize Log Insight, and others have in the past required solution certificates for this integration to be possible.

Below is an example of a vCenter Server 6.7 installation with vROPs and other integrations.

A vCenter Server 6.7 installation showing the previous Solution Certificates integrated with vCenter

With vSphere 7, the concept of solution certificates has been deprecated in favour of a much easier and less complex method of integrating these types of solutions with vCenter Server. The new method of integration is equally as secure as the solution certificates approach with less complexity.

Below is a vCenter Server 7 installation with vROPs and other similar integrations. As you will notice, there is no Solution Certificates listed. Additionally, this environment has vRealize Operations integrated among others. You will note, there is only the machine SSL certificate and the trusted root certificates listed.

Certificates Management in vCenter Server 7 is simpler and easier to manage even with integrations

New vCenter Server RESTful APIs for certificate management

VMware has greatly extended the ability to interact with vCenter Server in a programmatic way, via APIs. Just about all functionality in vCenter is exposed via API calls that can be used for automated interaction. As you can see below, in the Developer Center > API Explorer, you can search for “certificate” and see all the available API endpoints in vCenter for certificate management.

vCenter Server 7 certificate management RESTful APIs

Simplified vCenter Server and ESXi certificates

One of the overall improvements with certificate management in vSphere 7 is the simplified number of certificates needed for services in both vCenter Server and ESXi. There are essentially two ways you can manage certificates in the inner-workings of vSphere 7. You can allow the VMware Certificate Authority (VMCA) to manage them, or you can manually manage the certificates using your own PKI infrastructure. The VMCA is the preferred method as this allows vCenter Server to simply manage the certificates for you without the need to issue and install these certificates manually.

New certificate management modes

With the new certificate management changes in vSphere 7, VMware has introduced four new vSphere certificate management modes for managing your vSphere 7 certificates. These are essentially combinations of using the VMCA and using customized PKI infrastructure in varying degrees. What are these?

• Fully managed mode
• Hybrid mode
• Subordinate CA mode
• Full Custom Mode

Let’s look at these in more detail to see how each fit into the new management model for management vSphere certificates.

Fully managed mode is what we see with the default behaviour when vCenter Server is installed and the VMCA is initialized. When vCenter Server VMCA is initialized, a new root CA certificate is generated and installed. You can download this root certificate if you want to establish trust between clients accessing vCenter. You can also regenerate the VMCA root certificate to customize the cert for branding or other details. This is used for important infra-cluster communication between ESXi hosts themselves as well as between ESXi hosts and the vCenter Server. The VMCA also generates what is called the machine certificate. The machine certificate is the certificate that is presented to a browser session when browsing to the vCenter Server using the vSphere Client.

Hybrid mode is a good mix between the fully automated approach that is handled by the VMCA and manually managing certificates. For the most part, the main certificate that most will want to change or manage is the vSphere Client certificate. In larger environments where many will be accessing vSphere using the vSphere Client, it may be impractical to have each person download the root certificate from the vSphere Client to their local certificate repository. In this case, using the hybrid mode allows vSphere admins to replace the certificate that vSphere Client uses so that it is trusted for those accessing the vSphere Client using modern web browsers.

Aside from changing the vSphere Client certificate, in the hybrid mode, the VMCA is still allowed to manage and perform the deep automation of certificates between ESXi hosts in the vSphere cluster. This saves a tremendous amount of time and effort in managing the underlying certificates in the vSphere environment. In the hybrid mode, the ESXi hosts and vSphere Client have certificates that are signed by the VMCA by default. Many decide to simply rely on the signing of certificates by the VMCA, especially since these can be regenerated with customized information. This also provides a nice separation of certificate management and PKI infrastructure for customers who prefer to keep vSphere PKI infrastructure contained within vSphere.

The hybrid certificate management mode is the recommended certificate management mode for vSphere 7. It provides the best of both worlds in terms of both automating certificate management and having the ability to make use of customized certificates.

Subordinate CA mode is an interesting certificate management mode where the VMCA can operate as a subordinate CA that is delegated authority from a corporate CA. Operating in this mode allows vCenter to fully control and automate the certificate management inside the vSphere cluster. However, the difference with this mode is the certificates that are generated are trusted as part of the organization’s PKI infrastructure, being a subordinate CA.

Some organizations may want to make use of this implementation of certificate management in vSphere 7, however, there are some nuances to be aware of. When using this mode, you have to import “key” information into the VMCA that must be handled and stored securely. If any of the information is stored insecurely, an attacker can use this to compromise the environment with man-in-the-middle attacks. Many prefer the hybrid mode of certificate management for this reason as it generally helps to accomplish the same thing as the subordinate CA mode.

Full custom mode is perhaps the most complicated of the above modes listed. In this certificate management mode, an administrator is responsible for installing each and every certificate that is used in the vSphere cluster. VMware vSphere 7 provides a drastically simplified approach to the number of certificates that are used behind the scenes. However, this can still amount to literally dozens of certificates to manage. This is not for the “faint of heart”.

It can be complicated with production workloads as well since the regeneration of certificates on ESXi hosts requires the host to be disconnected and reconnected which is not a process that goes well with distributed switches and vSAN. Organizations who commit to this management model will be responsible for hundreds of keys, CSRs, and signing certificates. As you can imagine, this process is very error-prone and tedious.

vSphere Trust Authority (vTA)

With vSphere 7, VMware has looked for ways to bolster intrinsic security in the platform and to be able to utilize available hardware technologies on the market which can help to achieve this aim. The vSphere Trust Authority (vTA) is a tool that helps ensure that infrastructure is safe and secure.

VMware started the process to establish a solution for a trust authority back in vSphere 6.7. In vSphere 6.7, the Trusted Platform Module (TPM) 2.0 and the host attestation process was introduced. What is the Trusted Platform Module?

The TPM is responsible for doing three things in your vSphere environment:

• The first capability of the TPM is it can generate cryptographic keys and random numbers for various processes.
• Secondly, the TPM serves the purpose of storing very sensitive information like cryptographic keys, certificates, and signatures. A security mechanism that is inherent with the TPM is that it is cryptographically bound to the server on which it was first enabled. This helps to prevent anyone physically taking a TPM chip and trying to access the sensitive information it contains.
• Finally, the TPM chip can serve to determine if a system’s integrity has been breached. This process is called attestation. Basically, the TPM creates a thumbprint of how a healthy system looks from a security perspective. VMware vCenter can use these security measurements to make sure the physical ESXI host is booted with a non-compromised version of the software and configuration.

While the TPM features in vSphere 6.7 were a good start, vSphere’s actual use of the TPM and its ability to truly secure a host even if it failed attestation were limited. It was basically an alarm inside vCenter that was triggered. Workloads could still be migrated to a host that failed attestation. However, with vSphere 7, the vSphere Trust Authority (vTA) provides a much more robust attestation mechanism that is based on a management cluster that provides a “hardware root of trust”.

The cluster that serves as the “hardware root of trust” is a highly secure vSphere cluster that is scrutinized for its integrity and generally is a dedicated cluster that sits outside of the normal vSphere workload clusters in the environment. Generally, the vTA management cluster is a set of servers with a very small hardware footprint which do not run any workloads.

vSphere 7 Trust Authority (vTA) (image courtesy of VMware)

If a dedicated hardware root of trust cluster is not used, organizations can establish the vTA by simply using an existing management cluster. This can help to streamline the costs of setting up a dedicated vTA cluster and can be easier to get started for customers looking to delve into configuring the vTA in their environment.

Advantages of the vSphere Trust Authority (vTA)

The vTA in vSphere 7 provides really great security advantages when compared to simply using the TPM attestation in vSphere 6.7. These include:

• The vTA management cluster handles the task of distributing encryption keys from the Key Management Server (KMS) in vSphere. Since it means that vCenter is no longer responsible for holding the encryption keys, vCenter Server itself can now be encrypted.
• In addition, since the vTA is the entity that provides the attestation, it can actually withhold keys from hosts if they fail to satisfy the attestation process. However, when it comes to validating the integrity of a hypervisor host, this is the behaviour that is desirable since you do not want a potentially compromised host to house business-critical or even sensitive workloads.

Identity Federation

Traditional passwords in environments are becoming antiquated and are certainly one of the major security risks in your environment. This is why many organizations have adopted alternate identification means or additional “factors” of identification in addition to the traditional passwords. This is referred to as multi-factor authentication (MFA). Two-factor authentication is a popular type of MFA. Generally, with two-factor authentication, you need to know the password as well as present something “you have” such as a one-time passcode that is sent to your smartphone. This makes it exponentially more difficult for an attacker to compromise an account.

With vSphere 7 security, VMware has introduced the Identity Federation capability that allows attaching vCenter Server 7 to identity federation services such as Microsoft Active Directory Federation Services (ADFS). This allows vCenter Server to be bound to the same identity controls and capabilities defined by your existing authentication provider as well as take advantage of multi-factor authentication mechanisms tied to these identity sources.

Conceptual overview of vSphere 7 Identity Federation (image courtesy of VMware)

Once vCenter Server is attached to the authentication provider such as ADFS, logins will be redirected to the provider’s login page. Once the end-user logs in, which may include a multi-factor authentication mechanism, they receive a successful authentication token and are redirected back to the vSphere Client where they can successfully proceed.

This helps to strengthen and streamline the process of authentication in the vSphere Client and helps to ensure clients are using a uniform authentication mechanism with all the security fail safes. Centralizing management of authentication requests along with enabling two-factor authentication brings vSphere authentication to the same level of authentication protection as the rest of your environment.

Wrapping Up and Final Thoughts

VMware vSphere 7 is a landmark release in many ways, including security and compliance. The new features described help to bolster vSphere security using the latest and greatest security tools available to organizations today. VMware has touted the notion of “intrinsic security” for a while now. It is evident they continue to develop and integrate solutions that help businesses to have security as an integral part of the solution and not simply an “afterthought”, bolt-on solution.

VMware vSphere 7 also shows that increased security does not always mean new and flashy features. It can mean simplifying security processes and simply being able to integrate into existing security solutions as can be seen with the simplified certificate management and the identity federation capabilities with this release. As cybercriminals continue to use new and innovative attacks to compromise your environment, it is imperative that your organization stay on top of the latest tools that allow staying ahead of the attack curve. VMware vSphere 7 provides the tools needed to successfully secure your environment without overly complex and complicated processes or tools.