Encrypting VMware vSphere VDI VMs
You can use HyTrust DataControl to create an encrypted virtual desktop infrastructure (VDI), using VMware vSphere. This document describes the process, including:
- Initial setup of the Master VM
- Preparation for identifying clone VMs
- Deployment of clone VMs
- Cleanup at the end of the VDI life cycle
Creation of a Template From the Master VM
This section will describe how to set up a Master VM that contains the Policy Agent software and has one or more disks encrypted. We then show how to clone this VM and have the clone be identifiable to KeyControl and receive keys. The only initial differences between the clone and the Master VM will be the IP address and MAC address.
To create a Master VM and a template from this VM, follow these steps:
- Set up a Master VM with all the software / configuration according to the VDI requirement.
- Install the latest HyTrust DataControl agent on the Master VM.
- Register the Master VM with the KeyControl.
- Encrypt required data disks.
- If required, encrypt the root / system drive.
As a precaution, take a snapshot of the Master VM at this point.
Preparation for identifying clone VMs
By default the KeyControl does not provide the encryption keys to any clone VMs. When a clone is taken from the Master VM, it will have a different MAC address and a different IP address. We can use the MAC address to identify the clone VM to the KeyControl.
You need to run the following command on the Master VM prior to creating a clone:
To identify the clone VM by the expected MAC address, you should run:
hcl template -m <> -u username -p password expirationMAC address of clone
Where:
username
: Cloud Admin username, for example “secroot
”
password
: Password of the above user
expiration
: the number of days for which the access will remain valid for the clone, after which it will not be able to register and function independently. (Note: A value of 0 means no expiration.)
You can view the list of added identities using the following command:
#
hcl template list
There can be only one call per IP address. The KeyControl credentials must be entered on the command line or passed as arguments. As an example, if we wish to set up clones in the range 192.168.140.150-180, with a validity period of 365 days, you could run a Linux shell script (or the equivalent on Windows) as follows:
i=150
while [[ $i -lt 181 ]]; do
hcl template -i 192.168.140.$i -u username -p password 365
i=’expr+1’
done
Once this is done, the Master VM is ready to be cloned. You should now power off the Master VM and convert it to a VM template. The vSphere client provides a way to convert a VM to template and vice-versa. Note that converting to a template is NOT a requirement for HyTrust VDI support to work properly.
You can remove a previously added identity using the following command:
# hcl template remove -m <MAC address of clone> -u username -p password
Deploying Clone VMs
Having prepared your clone strategy, you can deploy clone VMs from the Master VM template. When a clone VM is deployed, it should be assigned a MAC address that was previously registered using hcl template
command. Alternatively, the VMware network settings should be configured such that the clone VM gets one of the IP addresses that was registered using the hcl template
command.
If the root drive of the clone was encrypted, when the clone VM boots, it will contact the KeyControl during boot. The KeyControl provides the keys for root drive and lets the clone VM boot. If the root drive was not encrypted, it will simply boot normally.
After the clone VM boots successfully, it will contact the KeyControl and re-register itself as an independent VM. If you login to the KeyControl WebGUI, you will notice that a new entry has appeared when you click the Cloud Icon and then click VMs. The clone VM registers with the following name:
<original hostname>-<mac address of clone>
For example:
win7master-0080c08f45c8
If you want to register more IP addresses or MAC addresses, you will have to convert the Master VM template to a virtual machine and boot it up. Occasionally you might have to re-authenticate the Master VM after it boots (during the boot, if the root drive is encrypted). This usually happens when the VM remains powered OFF for longer than the grace period. You can circumvent this by increasing the grace period for the Master VM.
NOTE: The key for the Master VM is copied to the clone. Rekey the clone to switch to a new key that is unique for this clone.
Cleanup
At the end of the VDI life cycle, the clone VM is deleted from the hypervisor. This can happen as a result of administrator action via the vSphere GUI, or via the VMware Horizon View GUI.
Before a clone VM is deleted, we need to unregister it from KeyControl. This removes the name of the clone from KeyControl, so that the same name can be used again later. Otherwise, you will have "orphan" names in your KeyControl, which will block you from reuse.
A VM can be unregistered from the KeyControl using one of the two following commands:
- If the VM is registered and authenticated then you can use
hcl unregister [-y]
-y
: if provided, will not prompt the user
- If the VM is registered, but is currently not in authenticated state, then you can use
hcl unregister [-y] -a [-u username -p password]
Where:username
: Cloud Admin username, for example “secroot
”password
: Password of the above user
After “hcl unregister
” none of the encrypted drives can be accessed on the clone VM. If the clone VM has its root encrypted, then soon after “hcl unregister
” it will power off.
A note on IP change
An IP address change (usually because of DHCP) has always been the most common cause of a VM getting unauthenticated. This will no doubt become an issue when the clone VM is rebooted later. If the DHCP lease expires, it will go to an “unauthenticated” state. Getting the clone VM into an authenticated state again requires the user to run “hcl auth -a
” command on the VM. This command asks for Cloud Admin credentials to complete the authentication.
If this proves to be an issue, you can disable the “Reauthenticate on IP change” check. There are two ways to disable this check:
- Login to the WebGUI, navigate to the VM details page and disable the check.
- Use “
hicli
” from KeyControl API package (see the note on “cleanup” for reference).
On a related note, you should not disable “Reauthenticate on Change of H/W signature” for the Master VM. If this check is disabled, the KeyControl can confuse the clone VM for the Master VM.
A note on cleanup
At the end of the VDI life cycle, the clone VM is deleted from the hypervisor. This can happen as a result of administrator action via vSphere GUI, or via the VMware Horizon View GUI. Alternatively, this can also be done using the scripting platform provided by VMware.
After a clone VM is deleted, we need to clean up its object in KeyControl. As said earlier it will appear in KeyControl as “mastervm-clonemac
”. Note: because the clone is registered in the same Cloud VM Set as its Master VM, the identity from the KeyControl’s perspective is “<Cloud VM Set of the Master VM> - <hostname-mac of the clone>
”.
The VM can be removed by hand using the GUI. Alternatively, DataControl provides an API package that can be used to clean up the clone object from the KeyControl. This API package is a bundle of Python scripts, which use the KeyControl REST API.
In addition to Cloud VM Set name and clone name, we require the Cloud Admin credentials to do the cleanup. The Cloud Admin credentials were previously described in the context of “hcl template
” command, in this document.
The API package comes as a tar-gzipped bundle, for example, hcs-api-3.0-7257.tgz
; this needs to be extracted on the machine from where we will run the cleanup script.
The primary interface in the API package is a command named “hicli.” You need to write a script as described below to implement the cleanup.
keycontrol=$1
cvmset=$2
clonevm=$3
username=$4
password=$5
hicli kc select $keycontrol
hicli user login $username --password=$password
hicli cvmset select $cvmset
yes | hicli cvm rm $clonevm
These commands can be run from a Linux machine or a Windows machine that has Python installed.