Encryption Within Virtual Machines with the DataControl Agent
Contents
- Introduction
- Platforms supported
- General Overview
- Installation of the DataControl Agent
- Managing the KeyControl list
- Managing Devices From the KeyControl Cluster
- Revoking VM Permissions
- Client-side Key Caching
- Managing Backups, Clones and Snapshots
- Moving Disks Between VMs
- Rekeying Disks
- Certificate Handling
- Timeouts (Heartbeat and Grace Period)
- Changing VM Defaults
- Summary of VM Status Reporting
Introduction
This chapter describes support for encryption within individual Virtual Machines (VMs) or physical servers wherever they reside (data center, private, public or hybrid clouds). For virtual machines, device encryption works independently of the type of the hypervisor platform (Type 1, Type 2, etc.) as well as the hypervisor vendor (VMware, Microsoft, Citrix, Red Hat, etc.) and Cloud environment (Amazon AWS, ENKI, Savvis, Rackspace, Microsoft Azure and Tier 3, to name but a few) or framework such as OpenStack. Throughout the chapter, we will refer to the virtualized case and reference the agent being managed by the KeyControl cluster as a "VM."
Platforms supported
We have currently tested on the following Linux platforms. We only support 64-bit versions:
- Centos 5.8, 6.2 and 6.3
- Ubuntu 10.04 server and desktop, 12.04 server, 12.10 server
- Red Hat Enterprise Linux 6
- Debian 6.0.7 (requires cryptsetup to be installed)
- Savvis Linux VMs:
- Red Hat Enterprise Linux Server 5.3 and 6.1
- Amazon Linux AMIs:
- Ubuntu 10.04, Ubuntu 12.04.1, AmazonLinux 2012.03
However, the DataControl agent should work on any modern version of 64-bit Linux. If the version you are running is not listed above, please contact us at support@hytrust.com and provide us with information about the version of Linux and the problems seen.
NOTE: Ubuntu 11.10 is no longer supported by Amazon.
We support the following Windows platforms:
- Windows 2008 Server R2 64-bit
- Windows 7 64-bit
- Windows 2012 Server
Note that the following features are currently not available on Windows (but coming soon):
- KeyIDs / encryption of objects to be passed between VMs or the datacenter and cloud storage.
- Support for Amazon S3 storage.
- Support for EFI/GPT partitions.
The following AWS instances support AES-NI:
m3.large m3.xlarge m3.2xlarge c3.large c3.xlarge c3.2xlarge c3.4xlarge c3.8xlarge g2.2xlarge r3.large r3.xlarge r3.2xlarge r3.4xlarge r3.8xlarge i2.xlarge i2.2xlarge i2.4xlarge i2.8xlarge hs1.8xlarg
Generally speaking, all "large" or "xlarge" instances support AES-NI while no micro or "medium" instances have AES-NI support.
General Overview
To understand the major components of the system consider the following figure:
A "Cloud Administrator" controls one or more "Cloud VM Sets" through the KeyControl cluster. Each Cloud VM Set can be considered a logical grouping of related VMs, for example "Amazon EC2 VMs," "Savvis VMs," "Legal Dept VMs," and so on. In addition to this logical grouping, authentication between the VMs and the KeyControl cluster requires the use of a per-VM certificate which is used during registration of the VM with the KeyControl cluster. Certificates can be revoked post-install which de-authenticates the VM that is tied to the certificate.
Cloud administration is performed by an administrator with Cloud Admin privileges. As with other administration roles, security administrators need to establish the Cloud Admin users and the Cloud Admin groups to which the user should be a member. For further information on User and Group management, refer to the chapter on Security Administration.. As a summary the following figure also shows the relationship between cloud admin groups and Cloud VM Sets:
Cloud admins are placed in Cloud Admin groups. Recall that all objects in the HyTrust universe are owned by groups and not by individual administrators. On the left of the figure, Jim and Bob are members of the "Department A" cloud admin group. Between them, they have created two Cloud VM Sets, namely "Amazon" and "Savvis." Jon is a member of the "Department B" cloud admin group and has created one Cloud VM Set called "Rackspace." It is not possible for Jim and Bob to see Jon or his Cloud VM Sets. It is also not possible for Jon to see Jim or Bob or their Cloud VM Sets.
To perform cloud admin operations, from within the webGUI, select the CLOUD tab. All of the available Cloud VM Sets for which the logged-on administrator is a member of will be displayed as follows:
In the example above there are three Cloud VM Sets: "Amazon AWS", "Savvis VPDC" and "MS Azure."
Before you can start adding VMs, you must first create a Cloud VM Set. To do this, select Cloud VM Sets in the file browser and click the CREATE CLOUD VM SET button (towards bottom right). You will then be presented with the following screen:
Once created, the Name will be visible within the file browser (under Cloud VM Sets). The Group is the Cloud Administration group to which the Cloud VM Set will belong. The Description is optional. Administrative groups are discussed in the Security Administration chapter. We'll describe Heartbeat Interval and Grace Period later.
Installation of the DataControl Agent
Although operation of the installed DataControl agent is similar across Windows and Linux, installation and adding devices to be encrypted is different. You can find out how to install the Linux DataControl agent here and the Windows DataControl agent here.
Installation of the KeyControl cluster is as described in the KeyControl Installation, Upgrade and Configuration chapter. When installing the KeyControl cluster we recommend that you mirror the system drives, have at least two KeyControl appliances for High Availability / DR purposes, establish sound KeyControl backup procedures, and ensure that the master key parts are well protected.
The overall steps to be followed to install and get going are shown in the follow figure:
The following sections discuss installation of the DataControl agent software and how to set up and initialize devices to encrypt. Note that you can perform all steps as a security admin since you have Cloud Admin privileges by default, granted during KeyControl appliance install. You are also a member of the default Cloud Admin Group. However, let's assume that you wish to set up a Cloud Admin user who will manage the VMs. To quickly summarize what is shown in the figure:
- Install the KeyControl server.
- As a Security Admin, create a user with only Cloud Admin privileges.
- As a Security Admin, place this user in a the default Cloud Admin Group or create a separate Cloud Admin group. In the figure we have created a Cloud Admin called "Jon", a Cloud Admin Group called "Department B" and added Jon to the "Department B" group.
- Jon then logs in and creates a Cloud VM Set called "Rackspace".
- Jon creates a certificate that is associated with the "Rackspace" group. He then downloads the certificate and the agent software and copies them to the VM. Please note that a certificate is needed for each VM and that each certificate is single-use only.
- Jon then installs the software and registers the VM with the KeyControl cluster. At this point he can now start adding devices to encrypt.
Once you have installed the agent and set up devices to be encrypted, please return to this chapter and review the following sections. Alternatively, read through the remainder of this chapter to get an understanding of features that apply to both Linux and Windows.
Managing the KeyControl list
Each VM needs to know the list of KeyControl appliances in the cluster in order to locate a running KeyControl appliance in the event that one appliance in the cluster fails. It is not always possible for the KeyControl cluster to be able to update each VM with the list of available appliances. For example, consider the following figure:
In this case, the KeyControl cluster is sitting behind a corporate firewall. According to each appliance in the cluster, the IP addresses are 10.238.32.90 and 10.238.32.91. However, the IP addresses used by each VM are referenced by Public_IP/port number, information that is invisible to the KeyControl appliances.
Each VM must be able to heartbeat an appliance in the cluster using the list of KeyControl appliances available. There are two options for managing the list, either:
- DNS is used to map a single KeyControl name to multiple IP addresses. Any time an appliance is added or removed from the cluster, the DNS entry must be updated.
- The hcl command must be invoked to keep the list up to date.
In the second option, consider the case where we have a single KeyControl appliance and a VM connected to it. hcl status shows the following:
# hcl status Summary -------------------------------------------------------------------------------- KeyControl: kc-1:443 KeyControl list: kc-1:443 Status: Connected
We have a single KeyControl appliance "kc-1". If we add a new appliance to the cluster, we should update the KeyControl list as follows:
# hcl updatekc kc-1,kc-2 Updated KeyControl list with KeyControl nodes kc-1,kc-2 # hcl status Summary -------------------------------------------------------------------------------- KeyControl: kc-1:443 KeyControl list: kc-1:443,kc-2:443 Status: Connected
Now we have two KeyControl appliances.
Note that on Windows you must add quotes around the KeyControl list so the above call will be:
C:\> hcl updatekc "kc-1,kc-2" Updated KeyControl list with KeyControl nodes kc-1,kc-2
Similarly, if we remove an appliance from the cluster, we should issue the call again to update the list. For example, to remove the second KeyControl:
# hcl updatekc kc-1 Updated KeyControl list with KeyControl nodes kc-1
It is extremely important that you keep the KeyControl list up to date to prevent device access from being revoked, and to prevent failure to get keys on a reboot.
Managing Devices From the KeyControl Cluster
The following figure shows the state of disks as they go from "FREE" (out of HyTrust control), to within HyTrust control and accessible by applications (attached), or to a detached state in which case access to decrypted data is not available.
Once devices have been added and attached, they can be viewed from within the webGUI. Select the Cloud VM Set and the VM from the file browser. Expand the tab for the VM and you will see the Disks tag. Expand this and the list of disks will be displayed. As an example, for Linux the screen will look similar to:
And for Windows the screen will look similar to:
The only difference is in device naming.
There are two operations that can be performed on disks. First, by clicking on the pencil icon, you can specify the expiration date of the key for this device. This is shown on the screen below:
When you specify a date, the expiration date will be displayed when selecting Disks from the file browser:
Once a key expires, what happens to the key depends on the key expiration option chosen. The default is NO USE which means that they key life can be extended by modifying the expiration time to some date in the future. If you have chosen SHRED, then when key expires it is destroyed. Also note that when the disk is removed, the key is expired at that time.
The second option is to revoke access to a device. This is achieved by clicking the X icon next to the device. Once revoked the GUI display will be updated as follows. Note that the padlock icon is now accessible. Clicking on it allows you to allow access to the device once more.
Once a device is revoked, if the filesystem on the device is mounted, it will be force unmounted on the next heartbeat and the device will be detached. In the screen shot above we can see that sdb2 has been revoked. When running hcl status, we will now see that the device is no longer attached:
sdb2 /dev/mapper/clear_sdb2 AES-256 Not attached '--> Handlers: attach = DEFAULT, detach = DEFAULT
An attempt to attach the device will now fail:
# hcl attach sdb2 Error on device getkey sdb1: Disk not ACTIVE Could not get encryption key for device sdb1 Failed to attach sdb1
On Windows the encrypted drives will simply disappear from view in Explorer and other applications. An attempt to attach the disk using hcl add will get the following:
C:\>hcl attach e: Error on device getkey \Device\Harddisk1\Partition1: Disk not ACTIVE Could not get encryption key for device e: Failed to attach e:
To restore access to the device to be attached again, you must enable it through the webGUI. When a VM's disks are displayed, there will be a padlock icon next to the device that was previously revoked:
Click on the padlock icon, confirm and the hcl attach will now complete successfully. In Windows, the drive will automatically be visible in Explorer. On Linux, you will need to remount the filesystem.
Revoking VM Permissions
You can revoke access to all devices for a VM and prevent further access between this VM and the KeyControl cluster until it is re-authenticated. Within the file browser, select one of the Cloud VM Sets and click the X next to the VM. The particular VM will immediately be moved back to the 'Unauthenticated' list.
One can also revoke VM access by selecting the VM from the file browser and clicking the REVOKE VIRTUAL MACHINE PERMISSIONS button.
On the VM, hcl status still shows that everything is fine (Connected).
# hcl status KeyControl: 192.168.140.151:443 KeyControl list: 192.168.140.151:443,192.168.140.152:443 Status: Connected
However, after the next heartbeat (10 seconds), the status changes as follows:
# hcl status Summary -------------------------------------------------------------------------------- KeyControl: 192.168.140.151:443 KeyControl list: 192.168.140.151:443,192.168.140.152:443 Status: Reauth needed (Virtual Machine not authenticated) Registered Devices -------------------------------------------------------------------------------- Disk Name Clear Cipher Status -------------------------------------------------------------------------------- sdb1 /dev/mapper/clear_sdb1 AES-256 Not attached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT sdb2 /dev/mapper/clear_sdb2 AES-256 Not attached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT
Filesystems on /dev/mapper/sdb1/2 have been force-unmounted and the devices have been detached. The VM needs to be re-authenticated again before the encrypted devices can be accessed. This is achieved as follows:
# hcl auth Enter passphrase (min 16 characters): onetimepassword16chrs Sent an authentication request to KeyControl node 192.168.140.128 Please log on to the KeyControl node to complete the authentication of this node
Return to the webGUI on the KeyControl cluster, navigate to the node and click the padlock icon next to the VM, and give the same passphrase (onetimepassword16chrs) ... and it will go back to its usual place in the group.
On the VM, one can now do an hcl attach -a to access encrypted storage again.
After the VM has been moved to the Unauthenticated VMs list, if you now delete the appliance (using the X icon) it will be permanently deleted from the KeyControl cluster. No re-authentication is possible, all keys are destroyed, and thus all storage using those keys is effectively useless. A new certificate must be created if the appliance is to be brought back to the fold.
Client-side Key Caching
Keys are delivered to the VM when it first boots and authenticates itself with the KeyControl cluster or when a new device is added, in which case the device is registered with the KeyControl cluster and a new key created. If the VM cannot access the KeyControl cluster for Grace Period seconds, access to the clear text devices will be revoked. Also, if the VM is not able to contact the KeyControl cluster on boot, keys will not be accessible.
HyTrust DataControl supports an off-line cached key mode whereby keys can be cached on the VM, wrapped with a password, for a specified period of time. In this mode, if the VM boots and is not able to access the KeyControl cluster, the keys can still be accessed by typing the passphrase.
Walking through an example, consider the following two devices:
Registered Devices -------------------------------------------------------------------------------- Disk Name Clear Cipher Status -------------------------------------------------------------------------------- sdb2 /dev/mapper/clear_sdb2 AES-256 Attached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT sdb1 /dev/mapper/clear_sdb1 AES-256 Attached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT
Now let's cache the key for sdb1. We'll cache for a single day. "HyTrust" is the passphrase that we will use to encrypt the keys in this example.
# date Tue Jan 29 13:47:12 PST 2014 # hcl cache -n 1 sdb1 Enter passphrase (min 4 characters): Re-enter passphrase: Cached keys for device sdb1 or # hcl cache -p HyTrust -n 1 sdb1 Cached keys for device sdb1 # hcl cache -l Cached keys for Devices -------------------------------------------------------------------------------- Disk Name Valid till -------------------------------------------------------------------------------- sdb1 01/30/13
Note that by running hcl cache -l you can see which devices have keys cached and for how long.
To demonstrate how caching works, let's shut down the KeyControl cluster and reboot the VM. Once the VM has rebooted, the clear text devices are not accessible since the KeyControl cluster is not reachable:
sdb2 /dev/mapper/clear_sdb2 AES-256 Detached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT sdb1 /dev/mapper/clear_sdb1 AES-256 Detached '--> auto_attach=ENABLED, attach_handler=DEFAULT, detach_handler=DEFAULT
Let's now get access to cached keys by typing in the passphrase (as entered earlier, the passphrase is "HyTrust"):
# hcl attach -l -a passphrase: Encrypted device sdb1 (/dev/sdb1) attached; decrypted contents visible at /dev/mapper/clear_sdb1 Could not get encryption key for device sdb2 Failed to attach sdb2 or # hcl attach -l -p HyTrust -a Encrypted device sdb1 (/dev/sdb1) attached; decrypted contents visible at /dev/mapper/clear_sdb1 Could not get encryption key for device sdb2 Failed to attach sdb2
We attempt to get keys for all devices but note that we only cached keys for sdb1.
Note that if you have different passwords for different devices, running a command such as the following will be limited:
# hcl attach -l -p HyTrust -a Encrypted device sdb1 (/dev/sdb1) attached; decrypted contents visible at /dev/mapper/clear_sdb1 Could not get encryption key for device sdb2
This command will only retrieve the keys for the devices for which the password is correct.
Once a user presents a password to unlock the keys, access to the filesystems will remain until either an explicit hcl detach or until the cache time expires. This presents a window when users cache keys but forget that they are still cached and active. We suggest that you review your procedures for caching carefully.
If you no longer wish a key to be cached, call the following with the -r option:
# hcl cache -a -r
The -a option in combination with the -r option will remove the cached keys for all devices. Alternatively, you can specify a single disk in place of -a.
Managing Backups, Clones and Snapshots
The HyTrust DataControl agent identifies the VM on which it is running and uses this information and the certificate supplied during registration in order to authenticate with the KeyControl cluster to fetch the necessary encryption keys. Any attempt to spin up a VM that looks identical (for example a VM snapshot) will fail to have keys delivered. This is obviously necessary from a security perspective, but presents challenges when dealing with VM snapshots, backups and clones. If one needs to go to a backup, it may be necessary to spin up a snapshot of the VM temporarily while data is being recovered.
HyTrust provides support for cloned VM images. For example, assume that we bring up a VM that has previously been backed up. When it starts up, the DataControl agent will attempt to communicate with the KeyControl cluster but will fail authentication if the original VM is up and running. This is what hcl status will report:
# hcl status Summary -------------------------------------------------------------------------------- KeyControl: 192.168.140.151:443 KeyControl list: 192.168.140.151:443 Status: Reauth needed (Hardware signature verification failed)
You can clone the information associated with the original VM allowing the cloned VM to gain access to the encryption keys. First of all, select the original VM from the file browser and click the CREATE CLONE CERTIFICATE button as shown below:
You should then copy the certificate to the clone VM and register once again with the KeyControl cluster. For example:
# hcl register -c -h "ubuntu-12.10" -d "My 12.10 VM" 192.168.140.151 bbd7d0c7-*_130415215216.bin Certificate passphrase might be required Certificate successfully unpacked You need to specify a passphrase which will be used for authentication with KeyControl Enter passphrase (min 16 characters): HyTrust Registered as ubuntu-12.10 with KeyControl(s) 192.168.140.151 Please log on to any KeyControl to complete the authentication of this node
Note that the only difference between this call and registration of any new VM is use of the -c option. Once you have typed the passphrase, you will be requested to authenticate the VM as usual within the KeyControl webGUI. At this point, the keys will be delivered and access to your encrypted devices will be granted.
Shown below is a screenshot of the original and its cloned VM side by side:
Moving Disks Between VMs
There are many examples of where it is necessary to move disks between one VM and another. Legal data can move between lawyers working on the same case, disks need to "migrate" between active/passive Windows cluster nodes, or per-patient healthcare information may be stored on separate databases on their own devices. There are certainly other ways in which similar workflows can be achieved, but migrating virtual disks is a very easy operation and has become increasingly popular.
HyTrust supports the migration of disks between one or more Linux VMs or between one or more Windows VMs. All VMs to which the disk will be moved must be in the same Cloud VM Set. We must therefore ensure that disks are self identifying by having a GUID stamped on the disk.
Regardless of the disk partitioning used (MBR or GPT), HyTrust will attempt to place a private region on the disk if space is available. This region is used to store partition GUIDs and other information that allow us to associate disks/partitions with their encryption keys and key versions. We cannot store a GUID on the disk if you have not partitioned it.
To make a disk portable, you don't need to do anything. We will add a private region when you run hcl add or hcl encrypt. If we are unable to add a region because there is no space to do so, we will issue a warning for EFI/GPT (since the disk is still portable) or give an error for MBR. An MBR disk can still be added but requires the operation to be forced (hcl add -f).
Disk portability is allowed between any VMs in a Cloud VM Set. Simply move the disk or copy it to a new VM and do hcl add <disk>. We will recognize the GUID, attach the device and obtain access to the keys.
Let's take a look at a Linux system by running hcl status:
Available Devices -------------------------------------------------------------------------------- Disk Name Device Node Size (in MB) -------------------------------------------------------------------------------- sdb1 /dev/sdb1 2047 sdc /dev/sdc 10
We have two disks available. We can look to see if they have private regions as follows:
# hcl status -g Device Discovery (Registered and Available) -------------------------------------------------------------------------------- Disk Name PartLayout GUID -------------------------------------------------------------------------------- sdb1 MBR N/A sdc MBR N/A
Both are MBR-formatted disks and currently have no associated GUID. Now let's add both disks and check again:
# hcl add sdb1 # hcl add sdc1 ... # hcl status -g Device Discovery (Registered and Available) -------------------------------------------------------------------------------- Disk Name PartLayout GUID -------------------------------------------------------------------------------- sdb1 MBR 8AF3AF24-351A-2FD4-C1AE-44094D259B3F sdb1 MBR 7AFFA524-459F-4F56-AC1E-5459E0259E3F
We can now see the associated GUIDs. At this point you are now able to copy this disk to another VM in the same Cloud VM Set.
On Windows, the GUIDs are displayed in the GUI and also by running hcl status, for example:
Device details ------------------------------------------------------------------------------- Drive Disk Part Cipher Status GUID ------------------------------------------------------------------------------- C: 0 2 none Avail-Sys N/A E: 1 1 none Available A8E25AE9-7A75-471A-A1AA-7CAE1550B35C F: 2 1 none Available 583EB883-52D3-4B05-A482-FF113B5359DD G: 3 1 none Available FF2A17F2-D7DE-404B-B977-018ADC611BCC
Note that all disks are available. In this case, we have used E:, F: and G: previously and they still retain their GUIDs.
An example of disk migration
To demonstrate how simple disk migration is, let's add a file to one of our Linux disks:
# mount /dev/mapper/clear_sdc1 /mnt # echo "hello world" > /mnt/myfile # umount /mnt
Here is its GUID:
sdc1 MBR 8182285F-1C43-400E-8E72-3105AE0D93A9
Next, we copy the disk (using whatever tools your hypervisor platform provides) to another Linux VM. Let's see what disks are available:
# hcl status -g Device Discovery (Registered and Available) -------------------------------------------------------------------------------- Disk Name PartLayout GUID -------------------------------------------------------------------------------- sdc1 MBR 8182285F-1C43-400E-8E72-3105AE0D93A9 sdb1 MBR N/A
Notice that the GUID matches. Now let's add the device and see if our file is there:
# hcl add sdc1 Encrypted device sdc1 (/dev/sdc1) attached; decrypted contents visible at /dev/mapper/clear_sdc1 # mount /dev/mapper/clear_sdc1 /mnt # cat /mnt/myfile hello world
As a final word, the procedure is the same in Windows.
Rekeying Disks
Off-line rekey is supported on both Linux and Windows. Dynamic rekey is available on Windows. For further information please refer to this section.
Rekey is a very straightforward operation and does not need any interaction through the webGUI. The following session shows a filesystem that is mounted with several files at the top directory. We then unmount the filesystem, issue the rekey command, remount it and show that the files are still accessible.
# mount /dev/mapper/clear_sdc1 /mnt # ls /mnt file1 file2 file3 files.tgz lost+found/ # umount /mnt # hcl rekey sdc1 All the data on /dev/sdc1 will be rekeyed The clear text data will be available on /dev/mapper/clear_sdc1 This operation may take long time Do you want to proceed? (y/n) y Starting rekey of sdc1 In case of failure run 'hcl rekey [-u] sdc1' total device size 10206 KB Processing: 100% Time left: 00:00:00 Completed rekey of sdc1 successfully # mount /dev/mapper/clear_sdc1 /mnt # ls /mnt file1 file2 file3 files.tgz lost+found/
If you have rekeyed previously, you will see the following additional prompt:
# hcl rekey sdc1 WARNING: rekey operation was successfully performed for device sdc1 Run rekey again Do you want to proceed? (y/n) y All the data on /dev/sdc1 will be rekeyed The clear text data will be available on /dev/mapper/clear_sdc1 This operation may take long time Do you want to proceed? (y/n) y Starting rekey of sdc1 In case of failure run 'hcl rekey [-u] sdc1' total device size 10206 KB Processing: 100% Time left: 00:00:00 Completed rekey of sdc1 successfully
You will also see a similar prompt if you have already encrypted or decrypted a disk.
If the operation fails for any reason, for example a system crash, by running the rekey operation again, you will see the following:
# hcl rekey sdb1 WARNING: Incomplete rekey operation detected for device sdb1 Continue rekey Do you want to proceed? (y/n)
and if you wish to reverse a rekey that only partially completed:
# hcl rekey -u sdb1 Starting undo of rekey operation on sdb1; In case of failure run 'hcl rekey -u sdb1' again Processing: 100% Time left: 00:00:00 Completed undo for sdb1 successfully
Certificate Handling
When certificates are generated, they are valid for 365 days by default, but you can specify the amount of time for which they are valid. At the time of expiration, the VM will be forced to re-authenticate. It is vital that if you wish to continue running without interruption, you generate a new certificate and apply it before the current certificate expires. To view the existing certificate expiration date for a VM, select it from the file browser as shown below. The expiration date is shown towards the bottom of the screen.
On the run up to certificate expiration, you will see several alerts that inform you that expiration is pending. See the section below on Managing Alerts for further information.
Before a certificate expires, you will need to generate a new certificate by clicking the DOWNLOAD NEW CERTIFICATE button shown above (not the CREATE NEW CERTIFICATE button associated with the Cloud VM Set). Copy the certificate to the VM, log on and update the certificate as follows:
# hcl updatecert [-p certificate_password] /path/to/cert.bin
If you do not use the -p option, you will be prompted for the password. The devices will stay attached through this process.
Displaying Unused Certificates
Unused certificates belonging to each Cloud VM Set are displayed in the Cloud VM Set detail page as shown below:
These certificates can be deleted. A "Certificate deletion" alert is generated on deletion. A default description is created for every certificate. In case of fresh certificates, it is a message of the form:
"Created by <username> at <datetime>"
In case of clone certificates, it is of the form:
"Clone of <VM-name>, created by <username> at <datetime>"
This description is inherited by the VMs created using these certificates, and can be changed at the time of registration or later. The certificate expiration date is also shown. The certificate expiration date is shown for all VMs in a sortable column. When a new certificate is applied to an existing VM (using hcl updatecert), the new expiration date is automatically updated on the KeyControl cluster.
Timeouts (Heartbeat and Grace Period)
If connectivity between the VM and the KeyControl cluster is lost after Heartbeat seconds (10 by default), the VM will continue running but hcl status will indicate that the KeyControl cluster is not reachable. For example:
Summary -------------------------------------------------------------------------------- Key server: 192.168.140.128:443 Status: Could not connect
Once the KeyControl cluster becomes reachable again, the status will switch to Connected. Similarly, from the view of the KeyControl cluster, if the VM is down or unreachable, the VM's status will be updated as follows:
The value set for the Grace Period is important. The default is 24 hours, expressed in seconds (86,400 seconds). If the VM is not able to heartbeat for Grace Period seconds, all permissions will be revoked, access to the unencrypted data will not be available and the VM must be re-authenticated before access is granted again. If the time for the heartbeat is G seconds, then revocation will take place some time between hitting the Grace Period and G seconds afterwards.
The values of the Heartbeat and Grace Period can be altered from within the webGUI by editing the VM information. There is no limit to the values that the Heartbeat and Grace Period can be set to. See Changing VM Defaults for further details.
Changing VM Defaults
You can change the default Heartbeat and Grace Period values for any VMs you subsequently create by clicking the Cloud VM Sets field on the file browser and then clicking EDIT DEFAULT SETTINGS. You will then see the following screen:
Note that by default, the Grace Period is set to one day and the Heartbeat is set to 10 seconds. We recommend that you alter the Grace Period value to suit your needs. Be careful about changing the Heartbeat. Each operation you invoke in the VM (such as altering these values, revoking device access etc) will only take place on heartbeat intervals.
When creating or editing a Cloud VM Set, you can alter the values for both Heartbeat and Grace Period as shown below:
Note however, that these are the defaults for each new VM that will be added to the Cloud VM Set. If you wish to change these defaults on a VM-by-VM basis, you need to select the VM and change its values.
By clicking the EDIT VM button, there are several parameters that can be changed. All of these parameters were described above in the previous section. Notice that the Heartbeat interval and Grace Period values are specified in seconds. The VM edit screen is shown below:
You can also edit values for a VM by clicking on the pencil icon when viewing the list of VMs for a particular Cloud VM Set. This is shown in the screenshot below:
The values that can be changed for this VM are shown below:
- Description - a description of the VM
- Heartbeat interval
- Grace Period
- Re-Authentication parameters. For example, you can force an administrator of the VM to re-authenticate the VM on reboot.
Note that you see the default Cloud VM Set settings. You then have the ability to change both the Heartbeat and Grace Period for this VM.
Managing Alerts
There are various events which occur that will result in alerts being generated. Your Security Administrator should have configured mail settings such that alerts will be sent by email as well as being visible from within the webGUI on the KeyControl cluster. For example, here are a few alerts as seen from within the webGUI:
For each alert, a similar email will be sent to the cloud admin's account. For example:
Make sure that you can see events both in the webGUI and through email so that you are aware of any actions that need to take place.
For certificate and key expiration, alerts will be generated as follows:
- An alert is generated once a day if the key/cert expiration date is nearer than a week.
- An alert is generated once a week if the key/cert expiration date is nearer than a month.
- An alert is generated once a month (30 days) if the key/cert expiration date is nearer than three months.
- No alerts are generated up to three months prior to the expiration date.
- No additional alerts are generated after three months from the expiration date.
Summary of VM Status Reporting
In this section, we list the various states that are reported by running the hcl status command:
- Not registered - The agent software is installed but the VM has not yet been registered.
- Connected - Everything is in great shape - the VM can communicate with the KeyControl cluster.
- Could not connect - The KeyControl cluster is not reachable.
- Need to update certificate - The certificate for the is VM is no longer valid and should be updated.
- Reauth needed - The VM needs to be re-authenticated.
- Virtual Machine not authenticated - displayed when VM permissions have been revoked from the KeyControl cluster.
- Identity verification failed - displayed when permissions are not available because the VM heartbeat times out, or its IP address or hardware signature changed (for example a copied VM run with new IP address).
- Unknown error from KeyControl cluster - an unknown error has occurred. Please contact HyTrust support if you see this message.