Welcome back to vSphere 8 in the real world, and now we're going to discuss securing vMotion.
So during a vMotion, you can choose to either encrypt the migration of the information. So
basically what we're talking about is when we copy the memory of a VM from one host to another host
during a vMotion, by default that information was just transferred in clear text. There's no
encryption on it. We can choose to require encryption or to basically request encryption.
So what this will do is it will allow us to, like here I mentioned the CIA triad,
so confidentiality, integrity, and the authentication. So confidentiality means,
you know, no one's reading it but the person you want to. Integrity means it hasn't been
changed during the encryption. And then the authentication, we're making sure we know who
both parties are, right? So when we want to encrypt the vMotion, we want to encrypt the
transfer of that RAM or memory from one host to another during that migration process.
What basically we can say is we're going to require it or we would prefer it if we can,
if both parties are able to do this, if we have the correct parameters selected, if we have the
trust, you know, between them, if we have a certificate of authority configured and we
have certificates that work for this, both hosts do, then we will. But if we don't have all those
pieces and we can't do it encrypted, we'll just do it anyway. Or you can also say don't do the
encryption, just do it in clear text. Maybe you have a vMotion network that you're very comfortable
with that is isolated. It's only accessible by those hosts. You're not worried about anybody
getting in on, you know, on that network and spying. I'm not saying that's the path you should
go but maybe that is your mindset. So then you would say, okay, I'm not going to take on the
overhead of the, you know, of the CPU to encrypt it all and the transferring of the larger amount
of data and the decryption on the other side. I don't want to add that overhead to my host.
I trust my vMotion network. Of course, if you could trust all these networks that easily,
then, you know, we wouldn't have hackers, you know, all over the place all the time. So that's
something you need to look at. Maybe it's not so much that you trust your vMotion network that
extensively but the machines you're running in this cluster are, they're test dev and we're
not really running any real data. It's all made-up data or the data that's on these VMs isn't that
sensitive but we have other VMs that are far more sensitive and those ones we want to encrypt
or something like that maybe. Okay. So basically a way of is ensuring the integrity and the secrecy
of the information while it's being transferred if we choose to do a secure vMotion, if we choose
to encrypt the memory of the VM when it's moving from one host to another. Right. So we can require
it. We can say opportunistic and opportunistic means if both sides can do it, we will secure
the encryption of the other VM. And if one or the other side can't for whatever reason,
then we'll do it anyway. Disabled means I'm never going to try. I'm not going to try to negotiate
encryption of the vMotion. We're just going to always vMotion and Cleartext. Those are your
options there. So vMotion security requirements. So you need to have a KMS server. Right. We need
to have a KMS server running on both, that's available for both the hosts or all the hosts,
you know, in your cluster, both the hosts involved in this particular vMotion.
The destination host is going to be actively using an encryption mode that is going to,
you know, support this. Basically we want to make sure that both hosts are getting their
keys from a key management server that they can both use. We trust the certificate authority
that's issuing these certificates. And we also need to have trust, meaning that they both need
to be in a trusted authority. Now what used to be they were in the same vCenter server,
and because they're both members of the same vCenter server, they were trusted. But now hosts
can be in different vCenter servers. So if they're in different vCenter servers, how do we have that
trust? We can use what's called linked mode. vCenter servers that are in linked mode are going
to have hosts that trust each other because those vCenter servers are trusting each other. And that's
what the whole linked mode operation happens. So we can have our key management servers, and we can,
you know, get our keys from our vCenter server, and linked mode will allow us to have communication
so we can make sure that everybody is trusted. So again, we can now migrate from a host in one
vCenter server to another. That wasn't the case originally. When we first had linked mode,
we couldn't vMotion between vCenter servers. We could move things around, but it wouldn't be a
vMotion. Now we can actually vMotion between vCenter servers. That's why it's so easy to
migrate between environments, for example, on-prem to a cloud provider and things like that as well.
This secure vMotion with, you know, these trust authorities and things like that make this a lot
more possible. So how would we enable encryption on a VM? You're just going to select the VM.
You're going to edit settings. Click the VM options. You can go to select your encryption,
and you can say if you want it to be disabled, opportunistic, or required. So in this section,
there'll be an option for encrypting the VM. And just because you're encrypting the VM does not
necessarily mean that you're encrypting the vMotion, right? Encrypting the VM means that
we have all the pieces in place so that we can encrypt the VM on disk, right, on the local store,
the storage where it lives, whether it be the SAN or local or whatever. We have the pieces in place
for VM encryption on disk. Then there's another option. Do we want to encrypt the vMotion traffic?
And you'll have another option also for a fault-tolerant login encryption, all right?
But what we're talking about right now is the vMotion encryption, and our options for that
would be, again, disabled or opportunistic. If we can, we will. If we can't, we'll still vMotion.
Or required. Required meaning if the other site isn't able to use encryption, then I'm not going
to vMotion to them. I'll try and find another host to vMotion to that does support the encryption.
So we discussed securing vMotion and how to enable encryption on a VM for vMotion.
Let's jump into our demo environment, and I'll show you how to enable encryption on a virtual
machine. So here we are in our vCenter environment, and our demo virtual machine
is already selected. So we're going to select our virtual machine, and we're going to go to
edit settings. Then we'll go to our VM options, and we have encryption. And under encryption,
I can see I have the option to encrypt the entire VM. Now, this is talking about encryption on disk.
I don't have the right infrastructure in place, so this actually is not going to
work correctly for me, right? There's no key provider for this vCenter server configuring.
I can also do an option to encrypt vMotion, right? I can say it's disabled, I can say
opportunistic, or I can say required, right? And this would mean that the other site would also
need to be able to support a vMotion to it, right? Now, also, we have our fault-tolerant.
This is not really necessarily part of the vMotion, but our fault-tolerant encryption,
which means our fault-tolerant logging for running this VM in a fault-tolerant state,
this is where we would also go in and choose if it's required or opportunistic or disabled as well.
Okay. So, that is how you would enable VM encryption on a virtual machine in vCenter.