I’ve had a number of requests for recommendations on the “best way” to restrict access to the ESXi host console. While this is easily done using the ESXi Lockdown Mode feature I’m finding there are some admins who are still under the impression that lockdown mode doesn’t work, and in order to prevent access to the host console you need to disable the console service. While there were some challenges with lockdown mode in the past, things changed in ESXi 5.1.
Lockdown mode disables direct access to the ESXi host (both DCUI and vCLI) thus requiring the host be managed remotely from vCenter Server. While lockdown is available in all versions of ESXi it wasn’t really used prior to ESXi 5.1. The reason being that prior to 5.1 there could only be one fully privileged admin account on a host, that account of course being the root user. While it was possible to add additional user accounts to a host, and to use these accounts to log in, once you were logged in you would need to “su” (switch user) to root in order to get admin rights. So even with local user accounts, root access was still required to manage a vSphere host. As such it was easier, and less work, to skip the “su” step and just login directly as root.
Where this affected lockdown mode is because the root user has always been an exception to lockdown mode. Regardless if a host is running in lockdown mode or not, the root user can always login. Hence, prior to ESXi 5.1 even if a host was placed into lockdown mode, because the vSphere admins would always log in directly as root this meant that lockdown mode didn’t really do anything – everyone could still login regardless if lockdown mode was enabled or not.
Needless to say, this limitation of a single admin account coupled with the admins propensity to always login as root, and the fact that root is always able to override the lockdown mode, sort of defeated the purpose of having a lockdown mode. As such, prior to 5.1 the only way to prevent local access to an ESXi host (i.e. truly lockdown a host) was to disable the console service. While this worked, it had an undesirable side affect. Should the host ever get disconnected from vCenter you would have no way of accessing the host in order to troubleshoot the problem. You would literally become locked out of the host. Not a good situation to be in, especially when we are talking about vSphere hosts that are running mission critical workloads. If this ever happened the only way to recover, assuming you were unable to restore the host’s connectivity to the vCenter Server, was to to re-install ESXi. Again, not an ideal situation.
Fortunately, this all changed with ESXi 5.1. In the 5.1 release there were a number of security improvements made to ESXi, one of which fixed this lockdown mode dilemma. Specifically, we added the ability to assign full admin rights to named user accounts. With this we no longer have to rely on a single shared root account. We can now create separate user accounts for each admin (or even better, add the ESXi host to Active Directory ) and assign full admin rights to these users. Using these named user accounts admins now have full admin rights without requiring access to the root user password. With this, if a fully privileged admin user was to attempt to use their admin account to log in to a host running in lockdown mode the login would be denied, thus requiring the admin to comply with the policy that all hosts be centrally managed from vCenter.
In addition, we no longer have to worry about the risk of getting locked out. Should a host ever become isolated from vCenter you can still use the root account to override the lockdown mode and login. I recommend you vault your root user password, which for many simply means locking in a safe and restricting access. This way, you can control access to the root account, allow your highly trusted admins to temporarily access the password when needed. After the problem is resolved you can place the host back into lockdown mode and re-secure the root user password.
With this explanation on lockdown mode here are my recommendations on restricting access your ESXi host that are running ESXi 5.1 or later:
1. Add your ESXi hosts to Active Directory. This not only allows users to use their existing active directory accounts to manage their ESXi hosts, but it eliminates the need to create and maintain local user accounts on each host.
3. Vault the “root” password. As I noted above, root is still able to override lockdown mode so you want to limit access to this account. With ESXi versions 5.1 and beyond you can now assign full admin rights to named users so it’s no longer necessary to use the root account for day-to-day administration. Don’t disable the root account, set a complex password and lock it away in a safe so you can access it if you ever need to.
5. Enable Lockdown Mode. Enabling lockdown mode prevents non-root users from logging onto the host console directly. This forces admins to manage the host through vCenter Server. Again, should a host ever become isolated from vCenter Server you can retrieve the root password and login as root to override the lockdown mode. Again, be sure not to disable the root user . The point is not to disable root access, but rather to avoid having admins use it for their day-to-day activities.
Following these five simple steps will go a long way to securing your ESXi hosts without having to disable the service console.
For more information vSphere and ESXi Security please follow me on twitter @Kyle_Gleed.
