If you work in IT, then you have definitely observed an increased emphasis on security. The number of incidents involving security breaches has been increasing. If you aren’t one of the big enterprises out there, then your business will definitely take a big hit from such a security incident. In general, you should always keep in mind the following two Werner Vogel quotes:
- Dance like nobody is watching and Encrypt like everyone is.
- Security is everyone’s responsibility.
Keeping with this trend, VMware introduced Native Virtual Machine Encryption capabilities in vSphere 6.5. In this blog post, we will take a look at how vCenter, ESXi Hosts, and Key Management Servers work together to encrypt the virtual machine.
But, before we do that, let’s take a quick look at the Traditional Encryption Solutions:
- In-Guest Encryption: This method uses a preboot partition to control access to the encrypted partition. The system boots from the preboot partition, the system retrieves keys from a hardware device or software control and then uses this key to enable the encrypted partition to boot. This method requires an additional hardware or software component and as you can see, it has to be custom designed for each guest Operating system. As a result of all these, there is a lot of operational overhead when implementing this method.
- Infrastructure-Based Encryption: In this category, encryption can happen at various different hardware points in the datacenter.
- Self-Encrypting Drives (SEDs): In this approach, Data is encrypted as it is written to the disk. SEDs have built-in hardware which encrypts the stream of bits being written to the drive. Each drive is encrypted using a unique Media Encryption Key (MEK), which is in turn encrypted using a Key Encryption Key (KEK). A drive without a KEK is essentially a normal disk because if anyone moves the drive to a different system, the MEK will still work on decrypting the data stored on the drive. This method isn’t the most optimal solution when you are using a shared storage device, as the data has to travel from the point of origin to the drive in an unencrypted format.
- Array-Based Encryption: This approach is similar to the SEDs, but in this case, the encryption happens at the Array level rather than the individual drive level. The controller in the storage array encrypts the data as it is written to the disk. The storage controllers usually have a custom ASIC that act as an onboard key manager or they work with an external KMIP compliant key manager. Again the disadvantage with this approach is that the data is traveling through the network in plain text format.
- Fabric-Based Encryption: There are two primary ways through which we can achieve Fabric-Based Encryption:
- Host Bus Adapter (HBA): In this method, the data is encrypted when it leaves the server and enters the storage network. Since the encryption happens at the source/host, data doesn’t travel through the network unencrypted. But, a drawback with this approach is that encryption happens at a per-host level which might restrict workload portability in some scenarios.
- Switch-Based Encryption: In this method, the data leaves the host without being encrypted, but it is encrypted as soon as it hits the first network switch. Since each switch uses its own set of keys to encrypt the data, there are limitations when you want to scale your environment or move your workloads to maybe a different cluster.
After observing and learning from all these Traditional Encryption Solutions, VMware released the support for vSphere VM Encryption in vSphere 6.5. You can not only encrypt the new virtual machines that you create but also existing virtual machines in your virtual environment. Before we talk about the steps involved, let’s talk about what is encrypted and what isn’t:
- What is:
- VM Files
- Virtual Disk Files
- Host Core Dump Files
- What isn’t:
- Log Files
- VM Configuration Files
- Virtual Disk Descriptor files
The three components involved in this process are:
- Key Management Server (KMS): An external server that is responsible for generating and storing Key Encryption Keys (KEK).
- vCenter Server Instance: vCenter that manages the cluster of ESXi Hosts.
- ESXi Hosts: Virtual hosts which are responsible for encrypting the VMs running on them.
Now, let’s talk about the actual steps needed to encrypt a virtual machine.
- The vCenter Server requests Keys from the Key Management Server.
- The Key Management Server generates a set of Key Encryption Keys (KEK) and an associated ID and sends both of these to the vCenter Server.
- The vCenter Server only stores the Key-IDs and forwards the Key Encryption Key to the ESXi Host.
- The ESXi Host receives this KEK from the vCenter Server and uses it to encrypt the Data Encryption Key (DEK). The ESXi Host doesn’t use the KEK to encrypt the virtual machines. The Virtual Machines are encrypted using a locally generated Data Encryption Key (DEK), and the ESXi Host uses the KEK to encrypt the DEK, which is stored locally.
- The VM Encryption using the DEK is done using industry standard OpenSSL libraries.
- As you can see, neither the vCenter server nor the ESXi host stores the KEK locally.
- In a scenario when the ESXi Host reboots, the vCenter server the vCenter server requests the KEK back from the Key Management Server (KMS) using the associated Key-ID as a reference pointer.
- The KMS forwards the KEK to the vCenter server, which then forwards it to the ESXi Host, which can then continue with its operations.
This is a secure and easy way by which you can encrypt your virtual machines and applications right at the source. There is no need for data to travel through the network in plain text format. Since we are using vCenter, we can create policies that help us manage multiple VMs together rather than handling each VM individually. Another major advantage is that there is no need for any specialized hardware, Host Bus Adaptors or switches, which reduces the operational overhead significantly.
If you want to learn more about vSphere Security, you should definitely check out Mike Foley’s blog. That is my source for learning anything that’s new in vSphere Security.