Learn about security enhancements that are specific to the ESXi host, such as secure boot and strict lockdown mode.
- [Narrator] When VMware discontinued the use of ESX, and decided to only use ESXi, that was back vSphere 4.1. They dramatically increased the security capabilities of the host. But every new version, they continued to have additional security advancements. The most notable for the 6.0 and the 6.5 host, is capability to have strict lockdown mode, and then also the capability to have secure boot support for ESXi hosts and VMs.
So let's go into the hands on labs and take a look at what each one of these is and how you set it. In regards to strict lockdown mode, that's part of the security profile of a host. So I've clicked on ESXi 01a, and what I'm going to do is now click on the configure tab and we're going to go down and find the security profile for the host. When you first go into security profile, depending on what you've been on before, you might see all of the services and firewall settings and the edits for those.
But that's not where we want to be. We want to be down here, where it says lockdown mode and I want to click on edit here. Now, what lockdown mode does, is it keeps the curious out. And the curious could be an attacker, it could be just somebody who's experimenting but really isn't supposed to be there. If lockdown mode is disabled, it means that I as a vCenter administrator, I can get in. Which is normal. But also, I can get in to the host without using the vCenter by using SSH PuTTy, as long as SSH is open.
I've got access to get to the direct consul user interface of the host. That's okay if that's me, if that's an administrator, but that could be a problem if that was not an administrator, if it was some sort of attacker. So the normal lockdown mode that was introduced some time ago turned off those services so that a vCenter administrator could manage the host through vCenter, but then the only other way that the host could be managed would be locally at the direct consul user interface.
Or at least by using some third party tool that makes it look local. And so that was normal lockdown mode. Either I have to be a vCenter administrator, logged in with my credentials for vCenter, or I have to be local to the host. But some organizations might want it even stricter than that. They might want that the only way we can get in is as a vCenter administrator. Because everything that we want done, through our system, needs to be on the vCenter logs, and therefore we don't want anyone to be able to backdoor it and get into the configuration of the host and be able to change settings, or be able to do anything with the host that wouldn't be through the vCenter, that wouldn't be through the vCenter logs.
So basically, the direct consul user interface is stopped. And it doesn't get much stricter than that. So that's what these are for, and it depends on your particular organization and your organizational policies as to which one is going to be best for you. But one thing that you shouldn't do is use this exception users for any actual administrator. You say, what's it for then? Well it's for service accounts. For application accounts that need to be able to circumvent this.
It's not for people. They don't make it super clear in some cases that it's not, but here basically it says to keep lockdown mode uncompromised, you should add only user accounts that are associated with applications. Well what they really mean is application type of accounts, service accounts. Not a user account that actually connects to a flesh and blood person. The idea here is that all the rules should apply for everybody once you've decided what level setting you want.
So those are your choices for lockdown mode, and as I said the new one is the strict lockdown mode. That's new for vSphere 6 and 6.5. So that has to do with managing the host. And as we said, the platform of the host is secure because of the fact that we made sure that when the host booted up, that the platform was secure, that every boot loader, if we're using EFI, if we're using UEFI, which is unified extensible firmware interface, and as long as the host supports that, that type of technology is going to replace BIOS at some point because it's much more secure.
Every single piece of software that loads up from the beginning is verified that it is what I want it to be. And if you think about it, that makes a lot of sense. How can I try and make something secure if I didn't do it from the foundation of its boot up? But it that's the case with the host, then what about the virtual machines that I create that are going to be servers? Can I let it come through for the virtual machine as well? And the answer is yes, as long as the virtual machine hardware supports it and can have a place to create and hold the key that it needs to use and as long as the operating system that's on the virtual machine supports it.
So I'm going to look at this little Linux micro machine, and what we're going to do is we're just going to look at his settings. So I'm going to click on configure for this machine, and as you'll see under VM options, there's the option to go to boot options. And then under boot options, I've got that EFI secure boot is disabled right now. But I have this edit button over here. So I'm going to click on edit.
And under boot options, I have the option to change this. Notice it says BIOS recommended. So what it's basically saying is if you don't know what you're doing, don't experiment here. Because you could bring the thing to its knees. But if you do know what you're doing, then more power to you. So what we can do here is click on the dropdown, and change it to EFI, and then change this to secure boot. If we know that the host has secure boot and that we have a guest operating system in here that will support it.
So whether you actually use this in your organization or not will probably depend on how you use certificates and how you use public key infrastructure and how important all of these things are to you. But it is available now, and it wasn't available before vSphere 6.
- New host, web, and vSphere clients
- Configuration maximums
- Security enhancements such as VM encryption
- Kernel and host profile enhancements
- vSAN 6.5
- Configuring Network I/O Control v3
- vCenter High Availability
- Predictive DRS