VMware vSphere 6.5 – VM Encryption Details

VMware vSphere 6.5 brings also VM encryption. VM encryption will work by applying a new Storage policy to a VM. It is Policy driven. You'll be able to encrypt the VMDK and the VM home files.

There is no modification within the guest OS. It does not matter which OS you're running (Linux, Windows, DOS, iOS) or on which storage the VMs files are located (NFS, block storage, VSAN….). The encryption is happening outside of the Guest OS. The guest does not have an access to the keys.

The encryption works also for vMotion but both the source and the destination hosts must support it. We'll see the settings later in this post.

It will get a key from the default key manager. It will be per-VM policy application model. It is easy to manage and also scalable.

The example within vSphere Web client bellow – apply encryption policy to two sample VMs…

VM encryption – How it works?

You have an encrypted VM after you have applied an encryption policy too. Then, a randomly generated  key is created for each VM, and that key is encrypted with the key from the key manager.

When you power On the VM which has the Encryption Storage policy applied to, vCenter retrieves the key from the Key Manager, sends that down to the VM encryption Module and unlocks that key in the ESXi hypervisor.

So all IO coming out from the virtual SCSI device goes through the encryption module before it hits the storage module within the ESXi hypervisor.

All IO coming directly from a VM is encrypted.

The workflow on activating the VM encryption would look like this:

To Decrypt a VM?

You may ask: How do I decrypt a VM then? It is very simple. By changing the Storage Policy back to a Datastore default. The VM's files, the VMDKs will be decrypted.

PowerCLI anyone?

Yes, there will be a PowerCLI cmdlet which will be able to apply a policy, but also to report on which VMs are currently encrypted….

You'll be able to encrypt VMDKs only, OR also The VMs home files.

Who Manages encryption?

It is not vCenter server, which is only a client. The 3rd party Key management Server (KMS) is the one responsible for the encryption of the key and the management.

With that you may ask who will be able to manage encryption of your VMs? Does all your vSphere admins needs to have access to encryption? Possibly. But possibly NOT. VMware has created a new default role ”

VMware has created a new default role “No Cryptography Administrator“.

You'll find this new role within the Roles, as usually. The new role will have still all the other privileges like a “standard” admin, but less the Encryption rights.

There Power ON, Off, shut down, vMotion etc…

No operations like:

• Manage key servers
• Manage keys
• Manage encryption policies
• No console access to encrypted VMs
• No upload/download encrypted VMs

All permissions are customizable.

And perhaps there are some gotchas?

VMware vSphere 6.5 VM encryption – The gotchas!

You may ask. What are the gotchas? Yeah, there might be some. And they are, at least in v1.0 of the feature….

• The default KMS isn't from VMware – yes, this might be a showstopper for some. But there are many other KMS managers out there and VMware vSphere will be able to use those other KMS managers for the job….
• SAN Backup not supported – backup proxy backup type is supported but the backup proxy appliance has to be encrypted, and also the user account which is performing the backup has to have the Cryptographer.DirectAccess permission.
• Backup data is not backed up encrypted – the backup solution may provide its own encrypted mechanism. After restoring you have to have a policy in place to re-encrypt the restored VM.
• vCenter cannot be encrypted – At least on the same infrastructure. Logical, as, if vCenter cannot start-up and get the keys, then you're kind of in trouble.
• Not supported – some things are unsupported:
  • Suspend/resume
  • Encrypting VM with existing snapshots (if VM is already encrypted, you can't created snapshot)
  • Serial/Parallel port
  • Content library
  • vSphere Replication

A Key management protocol 1.1 has to be implemented in order for the Key manager to be compatible with vSphere 6.5. Here is a list (not exhaustive) of the principal key managers supported.

 

Encrypted vMotion

There are 3 settings which are possible on the per-VM basis:

• Disabled – do not use encrypted vMotion
• Opportunistic – use encrypted vMotion if source and destination hosts support it. If not it will do a normal vMotion.
• Required – allow only encrypted vMotion. If the source or destination does not support encrypted vMotion, then the vMotion fails.

How the encrypted vMotion works? The randomly generated key is created and added to the migration spec.

Then pushed to each hosts participating in the vMotion process, where the data going across the network are encrypted with the randomly generated key only for the migration process.

It is one-time generated random key, which is generated by vCenter (not the KMS).

vSphere Encryption looks pretty good by adding an additional layer of security to your data, but things should be discussed first. Who has and who has not the rights to encrypt VMs? How to proceed when the admin leaves the company? How to proceed when the admin account (with rights to encrypt) password is lost?

Then everything shall be thoroughly tested first, starting with simple (not production VMs). Keep in mind that this is a v 1.0 feature and that there can be some gotchas…

VMware vSphere 6.5:

• VMware vSphere 6.5 Announced !!
• VMware vSphere 6.5 – Native vCenter High Availability (VCSA 6.5 only)
• VMware vSphere 6.5 – HTML5 Web Client and More 
• VMware vSphere 6.5 – VUM, AutoDeploy and Host Profiles
• VMware vSphere 6.5 – HA and DRS Improvements
• VMware vSphere 6.5 Fault Tolerance (FT) Improvements
• VMware VSAN 6.5 – What's New?
• VMware vSphere 6.5 – VM Encryption Details – [This Post]
• VMware vSphere 6.5 Released – Start Your Download Engines
• How to Migrate Windows Based vCenter to VCSA 6.5 [Lab]

Check our VMware vSphere 6.5 Page for ALL details about new announces and releases.