Live migrations are a routine part of Hyper-V management. As a Hyper-V administrator, it is important to configure...
your Hyper-V deployment in a way that will ensure the security of your environment during virtual machine live migrations.
One of the most important decisions you will have to make to ensure secure VM live migrations is choosing an authentication protocol. Microsoft allows you to choose between Kerberos and Credential Security Support Provider (CredSSP). Microsoft recommends using Kerberos (with constrained delegation) whenever possible. Kerberos is more secure than CredSSP and is not subject to CredSSP's single-hop limitation for authentication.
Because the CredSSP protocol is less secure than Kerberos and using it introduces a number of logistical challenges due to its single-hop limitation, you might be wondering why Microsoft even provides it as an option.
A Hyper-V server can only participate in live migration if it is a domain member. In most cases, the Hyper-V servers that need to support live migration will be members of a common Active Directory (AD) forest. In these situations, you should be using Kerberos-based authentication. Kerberos works great for authenticating servers that exist within a common domain, or even within a common AD forest.
It is worth noting that Hyper-V servers might not always exist within a common AD forest. Microsoft designed Windows Server 2012 and 2012 R2 in a way that allows VMs to be live-migrated on an as-needed basis. For example, you can live-migrate a VM from a standalone Hyper-V server into a Hyper-V cluster. Similarly, you can live-migrate a VM from one host cluster to another.
In these types of situations, it is possible that the Hyper-V servers involved may not belong to a common forest. For instance, you may need to move a VM from a development forest to a production forest. In these types of situations, it is always best to use Kerberos authentication, if possible. However, Kerberos will only work if a forest trust exists (external trusts are inadequate). If no forest trust exists, then using CredSSP is the only option.
Whenever possible, it is best to avoid using CredSSP. CredSSP works by passing credentials to a remote computer to complete the authentication. The problem with this is that if the remote computer is compromised, then the credentials could also be compromised. According to Microsoft, these credentials could be used to gain control of the remote session.
Sequester and secure VM live migration traffic
Another way that you can improve live migration security is to use a dedicated network for live migrations. Doing so offers a couple of benefits. First, using a dedicated network improves live migration performance because live migration traffic does not have to compete with other types of network traffic. Second, the live migration process is more secure because live migrations are not exposed on nondedicated network segments.
When you configure live migrations on a server that's running Hyper-V on Windows Server 2012 or 2012 R2, you are given a choice of using any available network or using specific IP addresses for live migration.
If you choose to use a dedicated network for live migrations, then the network should be specified as an IP address range. For example, such a network might be entered as 192.168.1.0/16.
Another thing that you can do is to enter the IP addresses of specific Hyper-V hosts. When you enter an address (whether a network address or a host address), you are effectively granting Hyper-V permission to accept inbound live migrations from the specified source. Obviously, you do not want someone live-migrating a rogue VM to your Hyper-V host. So, you should consider specifying the IP addresses of the trusted Hyper-V servers for which you want to accept inbound live migrations.
As you can see, there are a number of security best practices to consider when setting up secure VM live migrations for Hyper-V. As a best practice, you should use Kerberos authentication whenever possible, but also implement constrained delegation in order to prevent Kerberos authentication from being abused. I also recommend using a dedicated network segment for secure VM live migrations and specifying the individual hosts that are allowed to participate in the live migration process.