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
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
vSphere 6.5 introduces audit logging, before vSphere 6.5 logs were more focused on finding root causes of a problem – not releate deep to IT operations or security use cases. For example, if a virtual machine was reconfigured from one storage adapter to another in logs we would find only “Virtual Machine <name> reconfigured”.
But now logs which are coming from vCenter via Syslog will contain data from vCenter Events. These logs will clearly show “Before” and “After” setting changes. This enhances the ability of IT and Security administrators to troubleshoot issues by providing information what was exactly changed in the vSphere environment.
Enhanced logging summary:
- Improved vCenter/ESXi event logs quality
- Informative auditing without having to enable verbose mode
- Structured vCenter Events SysLog Stream
- Minimal VC overhead
- Simplified deployment
- Enables upper level intelligence
- Customer auditing examples:
- VM was moved to a wrong network
- VM disk was deleted by accident
- VM was under/over provisioned
Now let’s see how to enable streaming VC events to remote syslog server :
NOTE!!! This feature is not available on Windows VC
1. Enable event syslog:
2. Configure connection parameters:
And finally let’s look at some examples of vCenter events audit quality:
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 🙂