vSphere 6.5 security features have been one of the main focus areas in this release and you will notice what I am referring to in this post.
We will be just looking the various vSphere 6.5 security features are available to us from Virtual Machines perspective.
So, What’s New in vSphere 6.5 Security for Virtual Machines?
- Virtual Machine Encryption.
- vMotion Encrption.
- Virtual Machine Secure Boot.
Let us look into each of these features more closely. I will try and create some more posts in the near future on how to set these up in the lab.
Virtual Machine Encryption
Now most of you admins must be aware that there are plenty of security software available in the market which will help with encrypting the operating system of your choice.
The reason that you do not see this too often is because Virtual Machine encryption comes with its own set of challenges and operational overhead.
So what did we do to address this? Well, Encryption will be done at the “Hypervisor” level and not inside of the Virtual Machine.
As I/O comes out of the virtual disk controller in the VM it is immediately encrypted by a module in the kernel before being sent to the kernel storage layer.
Another cool thing is that since the encryption is done at the Hypervisor level and not inside the VM, the datastore type, Guest OS does not really matter. Encryption can be done to any VMs on any type of storage. That’s insane!
The encryption of Virtual Machines is managed by policies using VAIO filters. So if you have wanted to apply encryption to any VM, you just have to add that policy to the VM and voila, it’s done. Once encryption policies are applied to the VM, VMDK, and VM home files will get encrypted.
We make use of something called Key Management software to generate keys which will be used to encrypt the Virtual Machines.
Key Management is based on the industry standard, KMIP 1.1. In vSphere, vCenter is a KMIP client and works with a large number of KMIP 1.1 key managers.
Another important thing to note is that the keys are not physically stored anywhere in the vSphere infrastructure, every time a new key is required, vCenter gets it from the Key managers.
As long as the VM is running on an ESXi host, the keys are stored in the ESXi host memory.
When Encryption enabled virtual machines gets powered on, vCenter server as a KMIP client retrieves the key from the key manager and send that down to the VM encryption module in the ESXi hypervisor and unlocks the key.
Graphics Source: VMware
What this means is the I can encrypt the vMotion operation of the Virtual Machine is from one host to another. This isn’t done by encrypting the network or anything.
vMotion Encryption needs to be enabled on a per-VM basis. When vMotion Encryption enabled Virtual Machine is migrated using vMotion, vCenter Server will randomly generate 256-bit key (it does not use the key manager for this key).
Along with this key, a 64-bit “Nonce” (an arbitrary number used only once in a crypto operation) is also generated. Both these packaged into the migration specification sent to both hosts.
As you can see from the above screenshot, there are three options in the Virtual Machine settings page:
- Disabled – vMotion Encryption not Enabled
- Opportunistic – It uses encrypted vMotion if source and destination ESXi hosts support it. If destination ESXI host doesn’t support, it performs the normal vMotion operation
- Required – It only allows the encrypted vMotion. If the source or destination ESXi host does not support encrypted vMotion, then the vMotion operation will fail.
Virtual Machine Secure Boot
This one is pretty simple. You do not have to go do anything extra in order to leverage this feature.
The Virtual Machine must be configured to use EFI firmware and then you enable Secure Boot with a checkbox. This currently works with Windows and Linux OS.
Once Secure Boot is enabled on Virtual Machines, It will allow only to load signed drivers into the Virtual Machine.