WEBVTT 00:00:00.000 --> 00:00:04.240 Welcome back to vSphere 8 in the real world, and now we're going to discuss securing vMotion. 00:00:07.440 --> 00:00:15.520 So during a vMotion, you can choose to either encrypt the migration of the information. So 00:00:15.520 --> 00:00:22.000 basically what we're talking about is when we copy the memory of a VM from one host to another host 00:00:22.000 --> 00:00:28.000 during a vMotion, by default that information was just transferred in clear text. There's no 00:00:28.000 --> 00:00:34.240 encryption on it. We can choose to require encryption or to basically request encryption. 00:00:35.599 --> 00:00:42.240 So what this will do is it will allow us to, like here I mentioned the CIA triad, 00:00:42.240 --> 00:00:48.639 so confidentiality, integrity, and the authentication. So confidentiality means, 00:00:48.639 --> 00:00:52.799 you know, no one's reading it but the person you want to. Integrity means it hasn't been 00:00:52.799 --> 00:00:58.560 changed during the encryption. And then the authentication, we're making sure we know who 00:00:58.560 --> 00:01:04.639 both parties are, right? So when we want to encrypt the vMotion, we want to encrypt the 00:01:04.639 --> 00:01:10.639 transfer of that RAM or memory from one host to another during that migration process. 00:01:13.040 --> 00:01:19.760 What basically we can say is we're going to require it or we would prefer it if we can, 00:01:19.760 --> 00:01:24.639 if both parties are able to do this, if we have the correct parameters selected, if we have the 00:01:24.639 --> 00:01:28.400 trust, you know, between them, if we have a certificate of authority configured and we 00:01:28.400 --> 00:01:35.279 have certificates that work for this, both hosts do, then we will. But if we don't have all those 00:01:35.279 --> 00:01:40.160 pieces and we can't do it encrypted, we'll just do it anyway. Or you can also say don't do the 00:01:40.160 --> 00:01:46.239 encryption, just do it in clear text. Maybe you have a vMotion network that you're very comfortable 00:01:46.239 --> 00:01:52.000 with that is isolated. It's only accessible by those hosts. You're not worried about anybody 00:01:52.000 --> 00:01:57.040 getting in on, you know, on that network and spying. I'm not saying that's the path you should 00:01:57.040 --> 00:02:03.040 go but maybe that is your mindset. So then you would say, okay, I'm not going to take on the 00:02:03.040 --> 00:02:08.559 overhead of the, you know, of the CPU to encrypt it all and the transferring of the larger amount 00:02:08.559 --> 00:02:12.880 of data and the decryption on the other side. I don't want to add that overhead to my host. 00:02:12.880 --> 00:02:18.559 I trust my vMotion network. Of course, if you could trust all these networks that easily, 00:02:18.559 --> 00:02:22.639 then, you know, we wouldn't have hackers, you know, all over the place all the time. So that's 00:02:22.639 --> 00:02:26.399 something you need to look at. Maybe it's not so much that you trust your vMotion network that 00:02:27.360 --> 00:02:32.639 extensively but the machines you're running in this cluster are, they're test dev and we're 00:02:32.639 --> 00:02:39.119 not really running any real data. It's all made-up data or the data that's on these VMs isn't that 00:02:39.119 --> 00:02:44.399 sensitive but we have other VMs that are far more sensitive and those ones we want to encrypt 00:02:44.399 --> 00:02:50.720 or something like that maybe. Okay. So basically a way of is ensuring the integrity and the secrecy 00:02:50.720 --> 00:02:56.479 of the information while it's being transferred if we choose to do a secure vMotion, if we choose 00:02:56.479 --> 00:03:02.880 to encrypt the memory of the VM when it's moving from one host to another. Right. So we can require 00:03:02.880 --> 00:03:08.800 it. We can say opportunistic and opportunistic means if both sides can do it, we will secure 00:03:08.960 --> 00:03:14.080 the encryption of the other VM. And if one or the other side can't for whatever reason, 00:03:14.080 --> 00:03:18.880 then we'll do it anyway. Disabled means I'm never going to try. I'm not going to try to negotiate 00:03:18.880 --> 00:03:22.240 encryption of the vMotion. We're just going to always vMotion and Cleartext. Those are your 00:03:22.240 --> 00:03:31.279 options there. So vMotion security requirements. So you need to have a KMS server. Right. We need 00:03:31.279 --> 00:03:37.679 to have a KMS server running on both, that's available for both the hosts or all the hosts, 00:03:37.679 --> 00:03:41.199 you know, in your cluster, both the hosts involved in this particular vMotion. 00:03:42.240 --> 00:03:47.440 The destination host is going to be actively using an encryption mode that is going to, 00:03:47.440 --> 00:03:52.960 you know, support this. Basically we want to make sure that both hosts are getting their 00:03:52.960 --> 00:03:57.440 keys from a key management server that they can both use. We trust the certificate authority 00:03:57.440 --> 00:04:04.320 that's issuing these certificates. And we also need to have trust, meaning that they both need 00:04:04.320 --> 00:04:10.399 to be in a trusted authority. Now what used to be they were in the same vCenter server, 00:04:10.399 --> 00:04:14.639 and because they're both members of the same vCenter server, they were trusted. But now hosts 00:04:14.639 --> 00:04:19.760 can be in different vCenter servers. So if they're in different vCenter servers, how do we have that 00:04:19.760 --> 00:04:24.720 trust? We can use what's called linked mode. vCenter servers that are in linked mode are going 00:04:24.720 --> 00:04:30.880 to have hosts that trust each other because those vCenter servers are trusting each other. And that's 00:04:30.880 --> 00:04:36.480 what the whole linked mode operation happens. So we can have our key management servers, and we can, 00:04:36.480 --> 00:04:42.079 you know, get our keys from our vCenter server, and linked mode will allow us to have communication 00:04:42.079 --> 00:04:48.640 so we can make sure that everybody is trusted. So again, we can now migrate from a host in one 00:04:48.640 --> 00:04:53.040 vCenter server to another. That wasn't the case originally. When we first had linked mode, 00:04:53.040 --> 00:04:57.440 we couldn't vMotion between vCenter servers. We could move things around, but it wouldn't be a 00:04:57.440 --> 00:05:02.000 vMotion. Now we can actually vMotion between vCenter servers. That's why it's so easy to 00:05:02.000 --> 00:05:07.279 migrate between environments, for example, on-prem to a cloud provider and things like that as well. 00:05:08.160 --> 00:05:15.040 This secure vMotion with, you know, these trust authorities and things like that make this a lot 00:05:15.040 --> 00:05:22.239 more possible. So how would we enable encryption on a VM? You're just going to select the VM. 00:05:22.239 --> 00:05:27.760 You're going to edit settings. Click the VM options. You can go to select your encryption, 00:05:27.760 --> 00:05:33.200 and you can say if you want it to be disabled, opportunistic, or required. So in this section, 00:05:33.200 --> 00:05:38.000 there'll be an option for encrypting the VM. And just because you're encrypting the VM does not 00:05:38.000 --> 00:05:41.359 necessarily mean that you're encrypting the vMotion, right? Encrypting the VM means that 00:05:41.359 --> 00:05:48.480 we have all the pieces in place so that we can encrypt the VM on disk, right, on the local store, 00:05:48.480 --> 00:05:52.480 the storage where it lives, whether it be the SAN or local or whatever. We have the pieces in place 00:05:52.480 --> 00:05:59.839 for VM encryption on disk. Then there's another option. Do we want to encrypt the vMotion traffic? 00:05:59.839 --> 00:06:04.239 And you'll have another option also for a fault-tolerant login encryption, all right? 00:06:04.239 --> 00:06:07.839 But what we're talking about right now is the vMotion encryption, and our options for that 00:06:07.839 --> 00:06:14.559 would be, again, disabled or opportunistic. If we can, we will. If we can't, we'll still vMotion. 00:06:14.559 --> 00:06:19.920 Or required. Required meaning if the other site isn't able to use encryption, then I'm not going 00:06:19.920 --> 00:06:24.799 to vMotion to them. I'll try and find another host to vMotion to that does support the encryption. 00:06:28.720 --> 00:06:35.119 So we discussed securing vMotion and how to enable encryption on a VM for vMotion. 00:06:35.119 --> 00:06:38.959 Let's jump into our demo environment, and I'll show you how to enable encryption on a virtual 00:06:38.959 --> 00:06:44.320 machine. So here we are in our vCenter environment, and our demo virtual machine 00:06:44.320 --> 00:06:51.440 is already selected. So we're going to select our virtual machine, and we're going to go to 00:06:51.440 --> 00:07:00.480 edit settings. Then we'll go to our VM options, and we have encryption. And under encryption, 00:07:00.480 --> 00:07:05.600 I can see I have the option to encrypt the entire VM. Now, this is talking about encryption on disk. 00:07:06.239 --> 00:07:09.279 I don't have the right infrastructure in place, so this actually is not going to 00:07:10.320 --> 00:07:14.959 work correctly for me, right? There's no key provider for this vCenter server configuring. 00:07:15.920 --> 00:07:23.440 I can also do an option to encrypt vMotion, right? I can say it's disabled, I can say 00:07:23.440 --> 00:07:29.359 opportunistic, or I can say required, right? And this would mean that the other site would also 00:07:29.359 --> 00:07:35.920 need to be able to support a vMotion to it, right? Now, also, we have our fault-tolerant. 00:07:36.559 --> 00:07:40.880 This is not really necessarily part of the vMotion, but our fault-tolerant encryption, 00:07:40.880 --> 00:07:45.040 which means our fault-tolerant logging for running this VM in a fault-tolerant state, 00:07:45.040 --> 00:07:50.079 this is where we would also go in and choose if it's required or opportunistic or disabled as well. 00:07:50.079 --> 00:07:59.920 Okay. So, that is how you would enable VM encryption on a virtual machine in vCenter.