When new feature Secure Boot is enabled, the UEFI firmware validates the digitally signed kernel of an operating system against the digital certificate stored in the UEF firmware. For ESXi 6.5 this capability is further leveraged by the ESXi kernel, adding cryptographic assurance of ESXi components.
ESXi is already made up of digitally signed packages, called VIB’s. (vSphere Installation Bundle) These packages are never broken open. At boot time the ESXi file system maps to the content of those packages. By leveraging the same digital certificate in the host UEFI firmware used to validate the signed ESXi kernel the kernel will then validate each VIB using the Secure Boot Verifier against the firmware-based certificate, ensuring a cryptographically “clean” boot.
ESXi Secure Boot operations
- Installation of un-signed VIB’s/code will be prevented if SecureBoot is enabled.
- Installation of un-signed VIB’s can only be done if SecureBoot is disabled in the BIOS
- Enabling SecureBoot after un-signed VIB installation will cause a PSOD at boot time
- If you are running unsigned drivers you cannot use SecureBoot
- VIB Certificate Chaining
Virtual Machine Secure Boot
Enabling Virtual Machine Secure Boot is as simple as just checking the box in the UI.
Virtual machines must be boot from the EFI firmware to enable Secure Boot. There is support for Windows, Linux and nested ESXi in the EFI firmware. In order for Secure Boot to work, the Guest OS must also support Secure Boot. Some examples are Windows 8 and Server 2012 and newer, VMware Photon OS, RHEL/Centos 7.0, Ubuntu 14.04 and ESXi 6.5. For virtual machines, enabling Secure Boot requires that the VM is running with “EFI” firmware. Note that you can’t just change the firmware for some OS’s. When using EFI firmware, the Secure Boot checkbox becomes enabled.
Another good news is that You can encrypt the vMotion of any VM, encrypted or not – encrypted VM’s will always use encrypted vMotion :
Disabled – do not use encrypted vMotion
Opportunistic – use encrypted vMotion if source and destination hosts support it.
Required -Allow only encrypted vMotion.
Note !!! Mixed cluster and you have a requirement of encrypted vMotion, then setting to “Required” will not let you vMotion to a host that doesn’t support it. (only vSphee ESXi 6.5 )
VMware add new vmkcypto framework subsystem to vmkernel. It is used by Virtual Mchine Encryption and vMotion for cryptographic operations :
Now let’s look at new vMotion process:
- As part of that, a 256bit random key and 64-bit Nonce is generated. The Nonce used to generate a unique counter for every packet sent over the network. This prevents replay
- The key and the Nonce are packaged into a vMotion Migration Specification is created for the vMotion. This spec is sent to both systems in a the cluster.
- The vMotion traffic begins with every packet being encrypted on Host A and the counter incrementing.
- The packets are decrypted on the receiving host and the vMotion completes
New encryption gives many possibilities but also make some impact to other tasks in our environment. Let’s consider backup implications – backup and restore of encrypted disks is possible with NBD and HotAdd transport, but SAN mode does not support encrypted virtual machine backup. No API change is involved – ESXi hosts encrypt by attaching an IO Filter. To back up encrypted virtual machines using HotAdd, the backup proxy must have been encrypted as well. The backup process requires “Cryptographer.DirectAccess” permission. Data on backup media will be not encrypted!
- SAN Mode backups not supported (SAN has no visibility in to encrypted content)
- No API changes to Backup products
- When using HotAdd the Backup Proxy VM must be encrypted
- Backup User must have “DirectAccess” permission
- Backup data is not backed up encrypted
- Not supported with VM Encryption
- Encrypting a VM with pre-existing snapshots
- vSphere Replication
- Serial/Parallel port
- Content Library
- Don’t encrypt your vCenter or PSC VM’s -> Because You need vCenter to get the keys!!!
Next new security functionality in vSphere 6.5 – encryption is implemented via Storage Policies. If You add to the vm an encryption storage policy it will encrypt the disk.
- No modification within the Guest.
- VM Agnostic
- Guest OS
- HW Version
- Policy driven
- Encrypts both VMDK and VM files
- No access to encryption keys by the Guest
- Full support of vMotion
Diagram below shows how it works:
- Register a VM on a host and configure the (new or existing ) VM with Encryption Enabled storage policy and KMIP server
- vCenter gets a key from the KMIP server. That key is used to encrypt the VM files and the VM Disks.
- VC loads the key into the ESXi hosts. All hosts that don’t have the key will get the key to support DRS/HA.
- Once the key is loaded into the KeyCache on the ESXi host, encryption and decryption of the disk will happen at the IO Filter (introduced in 6.0 U1) level.
But let’s ask who can manage vm encryption ?
… Security Administrators will manage KMS and keys only “subset” of vSphere Admins will / should manage encryption within vSphere. We have new default role “No Cryptography Administrator” , additional we got new vCenter crypto priviledges like : Encrypt, Decrypt, Manage Keys , Clone. So we basically can delegate encryption priviledges to varius admins via custom roles in the way that we well know from previous environment editions – below example :
Lets see how to add in our vCenter KMS configuration – it is straight forward You just need to find new tab at web client and add new connection :
… and finally examples of supported KMS servers (below is not a full list)
most KMIP 1.1 compliant key managers get the approval – but as usual verify with VMware interoperability matrix to have 100% sure
In this article I will try to point most important security enhancements in recently released vSphere 6.5 platform. As we can hear from “pre GA” sneak peek information VMware will build security in 3 areas:
- Secure access – logs monitoring and audit
- Secure infrastructure – hypervisor with minimal footprint = minimal attack surface and cryptographic option to provide SecureBoot
- Secure data – hypervisor-level encryption for VM data
Let’s go deeper into the technology – below is a list of implemented security features / technology in vSphere 6.5 that we will discuss in details:
- Enhanced Logging
- VM Encryption
- Backup and Restore encrypted VMs
- Encrypted vMotion
- Secure Boot – ESXi and VMs
I’ll provide links to the features above in the near feature. Please, stay tuned 🙂