VMware has stated this vision to deliver:

Comprehensive Security with End to End Datacenter Protection in a way that makes security easy to manage

secure_end_to_end

We all know that corners are cut with security when controls are too difficult and cumbersome to implement. If made simple and easy, there’s a greater chance of achieving end-to-end security for the environment.

In the past few years, VMware has been working to take security management out of the VMs and into the hypervisor itself and controlled via vSphere APIs.  So, all the new security features and enhancements are done outside the VM and the emphasis is on the governance and management of those VMs.

If you are responsible for vSphere Security, there are quite a few new things in this release that you might like so here they are!

Enhanced Logging

The first enhancement that vSphere 6.5 brings is the much improved logging. There is a lot of information being collected by vSphere that is never displayed as it’s not considered important in normal operation. Sometime, you have to turn on “Verbose” logging to see it.

What’s changing with vSphere 6.5 is that without having to change to verbose mode, you’ll be able to see a lot more information on what’s happening in the environment and also how’s doing what. Currently, only the person taking an action is logged and when but not what the action is e.g. adding RAM to a VM, rebooting something etc.

That’s incredibly useful to not only keep track on what actions are being done in the environment on a daily basis but also when integrated with LogInsight, dashboard can be made to filter on a lot more events. So, if number of CPUs is being changed on VMs a lot, that can be easily shown in dashboards and alerts can be set to trigger on such activity.

 

VM Encryption

This is a big one really! vSphere 6.5 makes it easy to implement encryption on VMs, without any modification within the guest. As the emphasis here is on manageability, encryption is enabled easily by using VM Storage Policies. In addition to that it doesn’t matter which OS it runs, which datastore it’s hosted on or hardware version – it can be encrypted regardless. Encryption is implemented on everything that makes up the VM and is fully-supported by vMotion.

VMs don’t have access to the encryption keys and the whole process is handled by vCenter and the hosts but what about administrators? Surely you don’t want them to have access to them either. So, it’s good that just for that reason, there’s a new role: No Cryptography Administrator.

No Cryptography Administrator is almost the same as a normal administrator, except that it can’t:

  • Have access to the KMS or keys
  • Do encryption operations i.e. Encrypt/Decrypt
  • Upload/download encrypted VMs
  • Can’t have access to console of encrypted VMs

VM data is encrypted using an internal key that is encrypted by the KMS (Key Management Server) key so the data can only be accessed by the holder of the Tenant/KMS key. The Customer is responsible for keeping it safe.

It’s important to remember that vCenter is just a KMS client in this case. It also doesn’t keep any keys. So, to provide the KMS functionality, you will need to use one of the many available third-party solutions.

Caveats

There are a few caveats though! Some of the things that are not supported with encrypted VMs:

  • Suspend or Resume
  • Encrypting it with pre-existing snapshot
  • vSphere Replication
  • Serial/Parallel ports
  • Content Library

Obviously, a few of them and something to bear in mind while implementing. One might think it being a big issue if machines with snapshot cannot be encrypted but to be fair, snapshots are not meant to be kept long-term so it should be possible to encrypt such VMs at some point, if required.

Encrypted vMotion

This is about vMotioning of VMs that are encrypted, not about the vMotion network being encrypted. As mentioned earlier, vMotion fully supports encrypted VMs. So, what are the options to ensure the data while traverseing the network is safe?

The answer is within the new VM Options that come wtih it. One of the three options mentioned below can be set on an encrypted VM to control the behaviour. They are:

Disabled: Means no encrypted vMotion.
Opportunistic: Uses encrypted vMotion if both source and destination hosts support it. Otherwise, it’s normal vMotion
Required: Can only use encrypted vMotion and fails if either host does not support encrypted vMotion

Secure Boot for ESXi and VMs

Another enhancement to security is UEFI Secure Boot option for ESXi. It relies on hardware that supports UEFI Secure Boot firmware but that means every VIB is verified at boot time. If there’s a failure on any VIB, the boot process will fail and will result in a PSOD (Purple Screen of Death).

In addition to that, once installed, Secure Boot will prevent installation of unsigned VIBs/code. Also, you won’t be able to run ESXCLI commands and ask it to not check signatures. Installation of any such VIBs or code will require disabling of Secure Boot in the BIOS but then upon boot, the host will PSOD. Which obviously means one can only have either Secure Boot or unsigned code but not both, which makes sense. There shouldn’t be any flexibility when it comes to security as exceptions create doubt and investigative overhead.

Secure Boot option is also available for VMs. You will have to go into “VM Options” to enable it (can also be set via PowerCLI). As you can tell, that has to be done on a per VM basis.

This is another very valuable option added for environments where security is paramount. Yes, there will be pain when trying to ensure all hardware is compatible and all it’s code is signed and any changes will also require signed VIBs etc. but if one is in such an environment, it’s typically accepted.

Conclusion

Addition of these security features will no doubt make vSphere more acceptable to highly secure environments and I am sure, the push must be coming from them, given that they are typically huge deployments and VMware has a lot to gain from a good relationship with them.

That, of course, benefits all those organizations too that are not as big but need to be secure and it’s good to know that security is also being given its deserved attention by VMware.

May that continue for long!

Disclaimer: As of writing (October 17, 2016), this information is correct and while it’s hard to imagine these features to change between now and release, there is always a possibility.