Well, Windows Server 2016 is finally generally available, and there is still so much more to explore.
Another major feature comes on the Hyper-V side: shielded VMs. Shielded VMs allow for a layer of security that is unprecedented in a hypervisor. The single most accepted risk in a virtualized environment comes from the VM admin. Even if this person doesn’t have rights to a VM, they can open the console and see what’s present, browse the datastore, attach the VMDK/VHD/VHDx to another VM, or use integration services/VMware tools to do operations inside the VMs.
Shielded VMs provide a solution for all of this.
To achieve this, certain hosts are designated as Guarded Hosts. These hosts are then qualified by attestation servers, or “guardian servers.” These guardian servers qualify that everything about the guarded hosts stays exactly the same as when they were first qualified and added to the list. This means that the hosts have to pass rigorous boot checking (every file in the boot process) as well as complete data validation. In other words, no one can possibly tamper with the hosts or they will no longer be qualified as a “guarded host” and allowed to run the shielded VMs. Only hosts that have an active connection to the attestation service are allowed to run shielded VMs since the configuration of the VM itself is encrypted in a manner where no other host can decrypt it to run the VM.
Next come the VMs themselves. Each VM in a shielded VM environment has its own trusted platform module (TPM) embedded in the virtual hardware. This TPM is required to decrypt the contents of the drive. Normally in the above scenario — where the admin doesn’t have the ability to boot up the VM — he would simply remove the VHDs from the VM, attach them to a new config file, and boot the VMs that way. However, since the drives are TPM encrypted within the VM itself, if the config is separated from the VM, the VM cannot boot since the TPM is no longer associated with the drives in order to decrypt them. This means that the VHDs that run a VM don’t have to be physically secure because even if they are removed from the secure environment, they can’t be booted outside of the attested, guardian hosts that are allowed to boot the encrypted config files and then let those decrypt the encrypted guests.
Furthermore the actual Hyper-V guest hooks are all disabled in this mode. Integration services cannot reach inside the VM, snapshots are crash consistent, console access is not allowed. The VMs, once in a shielded state, are completely protected from an administrator getting into the guest OS except through normal external means (SMB, RDP, etc.). This of course, causes its own set of problems …
First, the guardian servers (attestation service) are incredibly important to this environment. If that service goes down, then no host can power up any shielded VM anywhere — there is no getting around this. If the service is down, the VMs are dead to the world. This means that the guardian service needs to be highly available, like in a cluster (not running on these same hosts). Further, since integration services can’t get inside these VMs, production snapshots can’t work. Also, full image-level backups of the VMs can only happen in a crash consistent state. No file-level restores can happen, because the VHDs are encrypted when backed up. To achieve file level restores, an agent has to run inside the VM itself. However, those agents can’t do full restores because the whole copy of the VM needs to be backed up with configuration to be able to boot again. These restores also have to happen to another attested host for the restored VM to be able to boot!
So clearly, there are some downsides. That being said, if you truly need a secure virtualized environment, there is nothing from any competitor that comes close to the security of a shielded VM.
If you’re curious about what else Windows Server 2016 has to offer, check out our other posts.