Although VMware Inc.'s vSphere is relatively secure with the default installation, there are third-party products...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
-- some aimed at vSphere virtual infrastructure security and some that provide additional security configurations -- that should be considered. Before examining any third-party security option, however, get familiar with vSphere's built-in protection features in this vSphere Essentials guide.
Areas of vSphere security
Learn more about VMware security
Breaches that should never happen
Protecting a VMware environment
Debating VMware security
There are many areas within a vSphere infrastructure you should review related to security, among them:
- Network security
- Storage security
- ESXi shell security
- ESXi lockdown mode
- ESXi authentication and user management
- vCenter server single sign-on, users, groups, and permissions
- SSL certificates
- Virtual machine security
- General security practices
That's a lot to be concerned about. Here are my top five security steps you should take to ensure that your vSphere infrastructure is protected. For much more vSphere security details, see the vSphere 5.1 Security Guide and the vSphere 5.1 Security Hardening Guide. Those list hundreds of security tweaks you can make to vSphere and your virtual machines.
1. Use vSphere Update Manager
While vSphere and vCenter don't have a lot of patches that are released for them (unlike the Windows OS), the patches VMware does issue are important to apply. In fact, vSphere patches may be released so infrequently that you may not even recall how to apply them manually when it's time to install.
To confirm that your ESXi servers, virtual machine tools and vCenter servers are always up to date and to ensure that patches can be easily applied when needed, you should use VMware's vSphere Update Manager (VUM). VUM is included with every version of VMware vSphere. If you have a version of vSphere that includes distributed resource schedule (DRS), then VUM can work with DRS to ensure that, before hosts are upgraded and restarted, VUM can orchestrate virtual machines (VM) a DRS/high-availability cluster so that VMs never go down.
Additionally, VUM can tell you which hosts, VMware tools (on each VM), vCenter and other vSphere components need to be upgraded and then help you perform the installs.
Note: vSphere Update Manager in vSphere is compatible with the vSphere Web Client.
2. Disable ESXi shell and secure shell
By default, you cannot log in to the command-line access console of an ESXi host nor can you use secure shell (SSH) to access an ESXi host over the network (or transfer files with secure copy). Even though these are disabled by default, many admins turn them on immediately and leave them on. Having these on is a security concern and the vSphere Client warns you that they are active, via the summary tab of an ESXi host.
You can turn off SSH and ESXi shell on the console of each host or you can do it in the configuration tab under Security Profile.
3. Control root and administrator passwords and monitor usage
As with any operating system or application, controlling administrator-level access control is crucial. If the wrong person has root account or administrator account privileges, very bad things can happen.
ESXi hosts have "root" accounts and you will be forced to set the password during installation. Ensure that you are using a secure password and limit access to only a very few people. Best practices dictate that admins should set up their own named account and log in using that address instead of logging in with the root account. Optionally, you can configure ESXi hosts to authenticate to the Windows Active Directory (AD) so that admins can log in using their Windows-named account.
VMware vCenter (when run on Windows), by default, authenticates to the Windows AD and the Windows AD administrator is the vCenter admin. Thus, you must secure your Windows admin account just as you should for your Windows domain security. It's recommended to create your own vSphere admins administrative group in AD, put administrators into that group (based on their Window- named log-ins) and have them log in using their own accounts. This can be taken to the next level by creating groups for things like "vSphere Web Server Admins" or "vSphere Email Server Admins" and then matching these up to vSphere roles in vCenter.
If you use the new vCenter Server Appliance (vCSA), the default credentials are root" and vmware. Obviously, you need to change the root password to a secure password.
4. Use Host Profiles and Auto Deploy
Just because one server has a secure configuration doesn't mean that they all do. To ensure that all servers have the same secure configuration, you should use vSphere Host Profiles. Additionally, when initially deploying ESXi hosts, you should confirm they are deployed from the same template using Auto Deploy and then properly configured with Host Profiles. Both Host Profiles and Auto Deploy are part of vSphere Enterprise Plus.
When you want to make a mass change to hundreds of vSphere hosts (for security reasons, let's say), you can roll out that change en masse using Host Profiles.
5. Enable lockdown mode
The single best thing that you can do to secure ESXi hosts is to enable lockdown mode. When enabled, lockdown mode prevents anyone but the root user from logging directly into the host. That means that neither the scripts, the vMA appliance nor the vSphere Client will be able to talk directly to the ESXi host. Additionally, no user besides the root will be able to log in to the server console (even if he or she previously had access). With lockdown mode enabled, only vCenter can communicate with the hosts directly.
Enabling lockdown mode can be done on the console of your ESXi hosts or through the configuration tab under Security Profile.
While I have listed five steps that you can take to security your vSphere infrastructure, don't stop there!
Continue learning vSphere essentials and what you can do to better secure vSphere using the following links: