vSphere 6.5 is a turning point in VMware infrastructure security. What was mostly an afterthought by many IT folks only a few short years ago is now one of the top drivers of innovation for vSphere. Security has become a front and center focus of this release and I think you’ll like what we’ve come up with.
Our focus on security is manageability. If security is not easy to implement and manage then the benefit it may bring is offset. Security in a virtual infrastructure must be able to be done “at scale”. Managing 100’s or 1000’s of security “snowflakes” is something no IT manager wants to do. She/He doesn’t have the resources to do that. The key to security at scale is automation and in these new features you’ll see plenty of that.
VM Encryption
Encryption of virtual machines is something that’s been on-going for years. But, in case you hadn’t noticed, it just hasn’t “taken off” because every solution has a negative operational impact. With vSphere 6.5 we are addressing that head on.
Encryption will be done in the hypervisor, “beneath” 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 send to the kernel storage layer. Both VM Home files (VMX, snapshot, etc) and VMDK files are encrypted.
The advantages here are numerous.
- Because encryption happens at the hypervisor level and not in the VM, the Guest OS and datastore type are not a factor. Encryption of the VM is agnostic.
- Encryption is managed via policy. Application of the policy can be done to many VM’s, regardless of their Guest OS.
- Encryption is not managed “within” the VM. This is a key differentiation to every other solution in the market today! There are no encryption “snowflakes”. You don’t have to monitor whether encryption is running in the VM and the keys are not contained in the VM’s memory.
- 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. This brings choice and flexibility to customers. VM Keys do not persist in vCenter.
- VM Encryption makes use of the latest hardware advances inherent in the CPU’s today. It leverages AES-NI for encryption.
vMotion Encryption
This has been an ask for a long time and with 6.5 we deliver. What’s unique about vMotion encryption is that we are not encrypting the network. There are not certificates to manage or network settings to make.
The encryption happens on a per-VM level. Enabling vMotion encryption on a VM sets things in motion. When the VM is migrated, a randomly generated, one time use 256-bit key is generated by vCenter (it does not use the key manager for this key).
In addition, a 64-bit “Nonce” (an arbitrary number used only once in a crypto operation) is also generated. The encryption key and Nonce are packaged into the migration specification sent to both hosts. At that point all the VM vMotion data is encrypted with both the key and the Nonce, ensuring that communications can’t be used to replay the data.
vMotion encryption can be set on unencrypted VM’s and is always enforced on encrypted VM’s.
Secure Boot support
For vSphere 6.5 we are introducing Secure Boot support for virtual machines and for the ESXi hypervisor.
ESXI SECURE BOOT
With Secure Boot enabled, the UEFI firmware validates the digital signature of the ESXi kernel against a digital certificate in the UEFI firmware. That ensures that only a properly signed kernel boots. For ESXi, we are taking Secure Boot further adding cryptographic assurance of all components of ESXi. Today, ESXi is already made up of digitally signed packages, called VIB’s. (vSphere Installation Bundle) The ESXi file system maps to the content of those packages (the packages are never broken open).By leveraging that digital certificate in the host UEFI firmware, at boot time the already validated ESXi Kernel will, in turn, validate each VIB against the firmware-based certificate. This assures a cryptographically “clean” boot.
Note: If Secure Boot is enabled then you will not be able to forcibly install un-signed code on ESXi. This ensures that when Secure Boot is enabled that ESXi will only be running VMware digitally signed code.
VIRTUAL MACHINE SECURE BOOT
For VM’s, SecureBoot is simple to enable. Your VM must be configured to use EFI firmware and then you enable Secure Boot with a checkbox. Note that if you turn on secure boot for a virtual machine, you can load only signed drivers into that virtual machine.
Secure Boot for Virtual Machines works with Windows or Linux.
Secure Boot for Virtual Machines
Enhanced Logging
vSphere logs have traditionally been focused on troubleshooting and not “security” or even “IT operations”. This changes in vSphere 6.5 with the introduction of enhanced logging. Gone are the days where you’ll make a significant change to a virtual machine and only get a log that says “VM has been reconfigured”.
We’ve enhanced the logs and made them “actionable” by now sending the complete vCenter event such as “VM Reconfigure” out via the syslog data stream. The events now contain what I like to call “actionable data”. What I mean by that rather than just getting a notice that “something” has changed you now get what changed, what it changed from and what it changed to. This is data that I can “take action” against.
In 6.5, you will get a descriptive log of the action. For example, if I add 4GB of memory to a VM that has 6GB today, I’ll see a log that tells me what the setting was and what the new setting is. In a security context, if you move a VM from the vSwitch labeled “PCI” to the vSwitch labeled “Non-PCI” you will get a clear log describing that change. See the image below for an example.
Enhanced/Actionable Logging
Solutions like VMware Log Insight will now have a lot more data to display and present but more importantly, more detailed messages mean you can create more prescriptive alerts and remediation’s. More informed solutions help make more informed critical data center decisions.
