Chapter 11
Configuring Security
IN THIS CHAPTER, YOU WILL LEARN TO:
- CONFIGURE VCENTER SERVER ACCESS CONTROL
- Understand vCenter Server’s Predefined Roles
- Customize Roles
- Manage Permissions
- SECURE VCENTER SERVER
- Harden the vCenter Server Computer
- Remove Default Administrative Access to vCenter Server
- SECURE YOUR ESXI AND ESXI HOSTS
- Control Network Access to the Management Network
- Isolate the Management Network
- Delete Unnecessary Local Accounts
- Understand Lockdown Mode
- SECURE YOUR VIRTUAL MACHINES
- Configure Virtual Machine Isolation
- Harden the Guest Operating System
There’s a saying in the security community: “Security is a pursuit, not a goal.” In your VMware vSphere environment, security is required. This chapter presents a number of ways to help improve the security of the various components of your VMware vSphere environment.
Configure vCenter Server Access Control
Part of the security of any environment is ensuring that access to resources is controlled properly. Users should have access to only those areas necessary to do their job and should be able to do only the tasks that are applicable to that job. For example, a help desk technician might need the ability to change the power state of a virtual machine, but most likely he or she does not need the ability to create new virtual machines and should not have access to that feature.
As a key part of vCenter Server’s management functionality, vCenter Server provides role-based access control (RBAC) for the VMware vSphere environment. vCenter Server’s RBAC implementation provides granular control over the specific tasks users are allowed to perform on certain types of objects. This allows organizations to ensure that users are granted the appropriate level of permission on the appropriate subset of objects as determined by the needs of the organization.
There are three aspects to configuring access control, which you’ll learn about in this section:
- Using the predefined roles that are available with vCenter Server.
- Customizing roles when the predefined roles don’t meet the needs of your organization. You can create new roles and edit, clone, or remove roles.
- Combining users, groups, and roles into permissions that you assign to objects in vCenter Server.
Understand vCenter Server’s Predefined Roles
vCenter Server comes with a number of predefined roles. These roles provide a starting point for customers to create the roles that fit their organization’s administrative model. Here are the default roles available with vCenter Server:
No Access This role denies access to an object for a user or group. It’s primarily used to prevent a user or group that has permissions at some point higher in the hierarchy from having permissions on the object to which this role is assigned. You can use it to create exceptions, where a user or group has access to all the virtual machines in a folder or resource pool except for just a few.
Read-Only Read-Only allows a user or group to see the vCenter Server inventory and the power status of virtual machines. It does not allow the user or group to interact with any of the virtual machines in any way through vSphere Client or the web client.
Administrator A user or group assigned to an object with the Administrator role will have full administrative capabilities over that object in vCenter Server. A user or group assigned the Administrator role for a virtual machine can change the hardware assigned to the virtual machine, connect and disconnect media, start and stop the virtual machine, and alter its performance parameters.
NOTE A user or group with the Administrator role does not have any privileges within the guest operating systems installed inside the virtual machines. Those privileges must be assigned within that guest operating system instance.
Virtual Machine Power User (Sample) The Virtual Machine Power User sample role assigns permissions to allow a user or group to perform most functions on virtual machines. This includes things like configuring CD/DVD and floppy media, changing the power state, taking and deleting snapshots, and modifying the configuration. These permissions apply only to virtual machines. A user or group granted this role would not be able to change settings on objects such as resource pools.
Virtual Machine User (Sample) The Virtual Machine User role grants a user or group the ability to interact with a virtual machine, but not the ability to change its configuration. Users can operate the virtual machine’s power controls and change the media in the virtual CD/DVD drive or floppy drive as long as they also have access to the media they want to change.
NOTE vCenter Server’s permissions are granular. For instance, if you want a user who is assigned the Virtual Machine User role to be able to attach an ISO file or a floppy image to a virtual machine located on a datastore, they must also be granted the Browse Datastore permission. Otherwise, the user will only be able to change the CD or floppy media to his or her own client system’s physical CD/DVD or floppy drive.
Resource Pool Administrator (Sample) The Resource Pool administrator can manage and configure resources within a resource pool, including virtual machines, child pools, scheduled tasks, and alarms.
VMware Consolidated Backup User (Sample) The user given this role has the privileges required for performing a backup of a virtual machine using VMware Consolidated Backup (VCB).
Datacenter Consumer (Sample) The Datastore Consumer role is targeted at users who need only a single permission: the permission to allocate space from a datastore. Clearly, this is a very limited role.
Network Consumer (Sample) Similar to the Datastore Consumer role, the Network Consumer role has only a single permission: the permission to assign networks.
NOTE For environments using vSphere Client to manage ESXi hosts directly, only three roles are available: No Access, Read-Only, and Administrator. The additional roles are only present when you are using vCenter Server.
These roles can be granted on an object at any level in the hierarchy and the user or group that is assigned the role will have those permissions on that object and—if the inheritance box, labeled Propagate To Child Objects, is marked—any child objects beneath it in the hierarchy.
Customize Roles
The predefined roles might not meet the specific needs of medium to large organizations. In that case, you can customize the roles to exclude certain privileges or to include additional privileges. Or you might find that none of the predefined roles meet your needs, in which case you can create an entirely new role. vCenter Server provides the functionality to edit the predefined roles, delete roles, clone existing roles, and add new roles.
All of this functionality is found in vSphere Client by navigating to the Roles area either by using the navigation bar or by selecting View ⇒ Administration ⇒ Roles. The Roles area displays all the currently defined roles. Right-clicking on a role provides commands to clone, edit, or remove the role. An Add Role button is also provided just below the navigation bar.
NOTE The No Access, Read-Only, and Administrator predefined roles cannot be edited or deleted. To customize one of these roles, you should clone the role and edit the cloned copy of the role.
Create a New Role
To create a new role, perform these steps:
1. Connect to a vCenter Server instance with vSphere Client.
2. Select View ⇒ Administration ⇒ Roles.
3. Click the Add Role button.
4. In the Add New Role dialog box, specify a name for the new role.
5. From the list of privileges, select the privileges you want to grant to this role. For example, if you wanted to create a role for managing distributed virtual network settings, you would assign permissions out of the Distributed Virtual Port Group and Distributed Virtual Switch categories, as illustrated in Figure 11.1.
Figure 11.1: The Add New Role dialog box allows you to specify the privileges assigned to a new role on a granular basis.
6. Click OK to save the settings and create the new role.
You’ve now created the new role and can use this role in assigning permissions.
Edit an Existing Role
Editing an existing role is necessary when you find that a role includes privileges that should not be included, or fails to include privileges that should be included.
To edit a role to add or remove privileges, perform these steps:
1. Connect to a vCenter Server instance with vSphere Client.
2. Select View ⇒ Administration ⇒ Roles.
3. Right-click the role you want to edit and select Edit Role.
4. In the Edit Role dialog box, specify a new name for the role (if desired) and add or remove privileges from the list.
5. Click OK to save your changes and return to vSphere Client.
TIP You can rename the role in the Edit Role dialog box, or by right-clicking on a role and selecting Rename to rename the role.
Clone an Existing Role
Sometimes, you might find that you need a new role that is very similar to an existing role but with a few privileges added or removed. While you could create a new role and assign all the permissions manually, you will find that cloning the role is quicker, easier, and less error-prone.
To clone an existing role, perform these steps:
1. Connect to a vCenter Server instance with vSphere Client.
2. Select View ⇒ Administration ⇒ Roles.
3. Right-click the role you want to clone and select Clone. Alternately, select the role and click the Clone Role button just below the navigation bar.
4. A new role appears in the list of roles. Type a name for the new role, and then press Enter.
The new role is now available for you to customize as needed.
Remove a Role
When a role is no longer needed, you can easily remove it. Simply right-click on the role you want to delete and select Remove.
If the role is currently in use—meaning that one or more users have been assigned a permission with that role—vCenter Server will prompt you for the correct action to take:
- To remove the permissions, select Remove Role Assignments when prompted.
- To reassign the permissions, select Reassign Affected Users when prompted. You’ll have the option to select a different role to assign to the affected users.
Manage Permissions
After you have created the necessary roles, you must then combine those roles with a user or group to create a permission. You’ll then assign the permission to an object in order to put it into effect.
You can assign permissions from any of the inventory views: Hosts And Clusters, VMs And Templates, Datastores, and Networking. In all these different views, the process is the same.
To assign a permission to an object, perform these steps:
1. While connected to a vCenter Server instance, navigate in vSphere Client to the inventory view for the type of object on which you want to assign the permission. For example, if you want to assign a permission on a specific ESXi host, navigate to Hosts And Clusters view.
2. Select the object on which the permission should be assigned.
3. Select the Permissions tab from the content pane on the right.
4. Right-click in a blank area of the Permissions tab and select Add Permission. This opens the Assign Permissions dialog box.
5. Under Users And Groups, select the Add button.
6. Select the specific users or groups to include in the role. When you’ve added all the users and groups, click OK.
7. From the Assigned Role section, select the role you want to assign to the selected users and groups.
8. If you want the permission to apply to child objects, be sure to leave the Propagate To Child Objects check box selected.
9. If you need to add more users or groups with other roles, repeat steps 5 through 8.
10. When you are finished assigning roles to users and groups, click OK to return to vSphere Client.
The permissions will appear on the Permissions tab for the selected object. If you need to remove a permission, simply right-click the permission and select Delete. To change the role assigned in the permission, right-click on the permission and select Properties. vCenter Server will display the Change Access Rule dialog box to allow you to change the role assigned in the permission for the selected user or group.
With vCenter Server’s role-based access control, organizations can properly secure access to the objects and resources in their VMware vSphere environment by binding to an existing directory service such as Microsoft Active Directory or LDAP. This is an important part of every organization’s security efforts, but not the only part. In the next section, we’ll examine some other ways to help secure vCenter Server.
By now, you are well aware of the central role that vCenter Server plays in the management of your VMware vSphere environment. In addition to securing user access to objects and resources within vCenter Server, it’s also important to secure vCenter Server and the computer on which vCenter Server runs. In addition, you will want to lock down the default administrative access to vCenter Server, which unnecessarily exposes access to vCenter Server to users who may not need access to the virtualization environment.
Harden the vCenter Server Computer
A discussion of hardening the vCenter Server computer is really more of a discussion on hardening Windows Server. Some general guidelines to keep in mind include:
- Be sure to keep the vCenter Server computer properly patched and up-to-date on all security updates.
- Follow published best practices from Microsoft with regard to securing Windows Server when using a Microsoft hosted vCenter Server.
- Be sure to harden not only the vCenter Server computer, but also the computer running the vCenter Server database (if it is on a separate computer).
- Follow published best practices from the appropriate database vendor for the database server you are using for vCenter Server.
- In accordance with your organization’s security policy, properly install and configure antivirus agents, intrusion detection systems, and other security software.
- If possible, control network access to the vCenter Server computer using a firewall or access control lists (ACLs).
- Install an Internet-facing VUM server on a separate machine.
WARNING Using a firewall with Network Address Translation (NAT) enabled between the vCenter Server and the ESXi hosts might cause problems. Avoid the use of NAT between the vCenter Server computer and the ESXi hosts.
- If you are using Windows authentication with SQL Server, use a dedicated service account for vCenter Server. Don’t share an account with other services or applications.
- Replace the default self-signed SSL certificates with valid SSL certificates from a trusted root authority.
- Restrict physical access to the vCenter Server computer to authorized personnel only.
These are just a few guidelines to get you started; there are many, many more hardening guidelines available for securing Windows Server 2003 or Windows Server 2008. Although many different security guidelines and benchmarks exist to help you harden Windows Server, the best place to start is with Microsoft’s website at www.microsoft.com. From there, you will find documentation and references to other useful resources.
In addition to securing the operating system underneath vCenter Server, there are also some steps you can take to secure vCenter Server itself. One of these steps is removing the default administrative access to vCenter Server, as described in the next section.
Remove Default Administrative Access to vCenter Server
By default, when vCenter Server is installed on a Windows platform, the local Administrators group on the vCenter Server computer is granted the Administrator role at the datacenter object within vCenter Server. Effectively, this means that the local Administrators group is given full permission on all objects within the vCenter Server hierarchy. When the vCenter Server computer is part of an Active Directory domain, this also means that the Domain Admins group—which is, by default, a member of the local Administrators group on every member server in the domain—also has full permission on all objects within the vCenter Server hierarchy. This default administrative access exposes vCenter Server to personnel that may have no need for access within the VMware vSphere environment.
To remove the default administrative access in vCenter Server, perform these steps:
1. On the vCenter Server computer, use the Computer Management console to create a new local group. You could call the group vCenter Administrators or something similar.
2. Create a new user and place this user into the group created in step 1. Be sure not to place this user in the local Administrators group.
3. Log on to the vCenter Server computer using an account with administrative permissions.
4. Launch vSphere Client and connect to a vCenter Server instance.
5. Assign the Administrator role to the new group created in step 1 to the vCenter Server object at the top of the hierarchy. Be sure to leave Propagate To Child Objects selected.
6. Log off and log back on as the user created in step 2.
7. Log in to vCenter Server using vSphere Client and ensure that you are able to perform all tasks available for a vCenter Server administrator.
8. Remove the permission on the vCenter Server object for the local Administrators group.
9. If you are using Active Directory, create a group in Active Directory and add it to the local group created in step 1. Add domain users to the domain group as necessary.
After making this change, only the users that are members of the local group (or the Active Directory domain group, where applicable) will have administrative permissions within vCenter Server.
Secure Your ESXi and ESXi Hosts
In addition to securing access to the objects within vCenter Server and securing the vCenter Server computer, you need to appropriately secure your VMware ESXi hosts.
In each of the following sections, we’ll identify configuration steps to secure ESXi. This will make it easier to identify which security configuration recommendations apply to each product.
Control Network Access to the Management Network
To help control network access to the VMware ESXi Management Network, VMware supplies a firewall for the Management Network and a command to configure the firewall. You can configure the firewall via vSphere Client or via the command line. If you choose to use the command line, use the command esxcli network firewall to enable or disable network services through the firewall.
To view or configure the firewall from vSphere Client, perform these steps:
1. Connect to an instance of vCenter Server with vSphere Client. If there are multiple vCenter Server instances in your environment, be sure to connect to the instance that is managing the host you wish to configure.
2. Navigate to Hosts And Clusters inventory view using the View menu, the navigation bar, or the Ctrl+Shift+H keyboard shortcut.
3. Select an ESXi host from the inventory on the left.
4. Select the Configuration tab from the content pane on the right.
5. Select the Security Profile link under Software.
6. The current incoming and outgoing connections allowed through the firewall are listed in the content pane. If you need to make changes, click the Properties link.
7. In the Firewall Properties dialog box, check or uncheck the services whose state you need to modify. Check a service to allow it through the firewall; uncheck a service to deny it through the firewall. Figure 11.2 shows the Firewall Properties dialog box with some services enabled and other services disabled.
Figure 11.2: Firewall Properties dialog box
8. Click OK to return to vSphere Client.
To view or configure the firewall from the command line, perform these steps:
1. Using a terminal window, log in to the console of the ESXi host.
2. Use the esxcli network firewall command to view the current firewall settings:
esxcli network firewall get
3. List the defined services that are understood by the firewall with this command:
esxcli network firewall ruleset rule list
4. Enable a service through the firewall with this command:
esxcli network firewall ruleset -e true -r=<service name>
5. Disable a currently enabled service using this command:
esxcli network firewall ruleset -e false -r=<service name>
Changes made using esxcli network firewall take effect immediately, but may not be reflected in vSphere Client for a few minutes, or when you click the Refresh button.
NOTE For additional flexibility in controlling network access to the VMware ESXi host, you can also leverage other Linux-based network access control features, such as TCP Wrappers.
Isolate the Management Network
The VMware ESXi Management Network needs its own network connectivity to communicate with other VMware ESXi hosts and with vCenter Server. For ESXi, this network connectivity does not need to be shared with VMkernel traffic (used for VMotion, Fault Tolerance logging, or IP-based storage) or virtual machine traffic, so we highly recommend that you isolate the management network using either VLANs or a physically separate network. Redundancy of the management network is important, however, so be sure to include redundant network connections for the Management Network where possible.
Figure 11.3 shows a sample network configuration for a VMware ESXi host that places the management traffic onto a separate set of NICs. These NICs might connect to switches on a physically segregated network, or just to ports in a different VLAN on the same physical switches.
Figure 11.3: This network configuration allows for the VMware ESXi management traffic to be segregated onto a physically separate network.
When it isn’t possible to use separate ports in a different VLAN or a physically separate switch, you can run the Management Network on a different VLAN than VMkernel or virtual machine traffic. Refer to Chapter 6 for more information on how to configure VLANs.
Delete Unnecessary Local Accounts
In many environments, especially those using vCenter Server, the individual ESXi hosts will not have many, if any, unnecessary local accounts. In other environments, though, many local accounts might have been created on the ESXi hosts. When these accounts are no longer necessary, they should be disabled and removed to prevent possible unauthorized access to the hosts.
NOTE vCenter Server acts as an authentication proxy between the end users and the ESXi hosts. Rather than passing credentials through to the ESXi hosts, vCenter Server proxies all connections using a special account named vpxuser. Do not modify or delete this account on your ESXi hosts or you will break vCenter Server’s management functionality.
On a VMware ESXi host, you can delete unnecessary local accounts either using vSphere Client connected directly to the host, or via the Management Network with the userdel <username> command. If you prefer to keep the account but lock it so that it can’t be used for logins, use the passwd -l <username> command (that’s a lowercase L in the command). The passwd -u <username> command will unlock the account.
To use the vSphere Client to remove local accounts on an ESXi host, perform these steps:
1. Log in to the ESXi host directly using vSphere Client.
2. From the right content pane, select the Local Users & Groups tab.
3. Click Users.
4. Right-click the user you want to remove and select Remove.
Understand Lockdown Mode
Lockdown Mode, when enabled, prevents management of the ESXi host outside of vCenter Server. Direct connections to the ESXi host using vSphere Client are denied—all management requests must go through vCenter Server. This ensures that vCenter Server’s role-based access controls come into play and are not circumvented by connecting directly to the ESXi host. Limited administrative functions can also be performed at the local ESXi console. If a root password has been specified, it will be required before these administrative functions can be performed.
NOTE Be sure to specify a root password on all ESXi hosts.
The fourth major component of a VMware vSphere environment that you need to secure is the virtual machines themselves.
Not only do you need to secure the guest operating systems installed within these virtual machines, but you must also secure the virtual machines themselves. The fact that these are virtual machines, as opposed to physical machines, does introduce new security issues that must be taken into account in an overall effort to improve the security of the environment.
Configure Virtual Machine Isolation
One specific area that is unique to virtual machines is virtual machine isolation—how and when a virtual machine is allowed to interact with the virtualization layer.
Isolation is a key benefit of virtualization. It is the isolation of one guest operating system instance from other guest operating system instances that allows you to run multiple operating systems on the same hardware. It is the isolation of the guest operating system from the underlying hardware that gives virtual machines their hardware independence.
Some of this isolation is removed to simplify things for administrators. For example, administrators expect the ability to use copy-and-paste between their local computer and the console of a remote virtual machine. Enabling this greater interaction between virtual machines and the rest of the physical environment has to be weighed with a careful eye toward security.
The next few sections describe some of these isolation settings.
Disable Copy and Paste
By default, the remote console of vSphere Client provides the ability to use copy and paste to move data to and from a virtual machine to the local workstation. To prevent this functionality, disable copy and paste by adding the following lines to the virtual machine’s configuration file:
isolation.tools.copy.disable = "true"
isolation.tools.paste.disable = "true"
You can either edit the virtual machine configuration (.vmx) file directly, or you can add these entries using vSphere Client.
NOTE Editing the virtual machine configuration file directly is more error-prone than using vSphere Client to modify the virtual machine configuration.
To add entries to a virtual machine configuration file using vSphere Client, perform these steps:
1. Launch vSphere Client, if it is not already running, and connect to a vCenter Server instance.
2. Navigate to an inventory view that displays the virtual machine you wish to modify. The virtual machine must be powered off to make the changes; if necessary, shut down the virtual machine first.
3. Right-click the virtual machine and select Edit Settings.
4. Select the Options tab, click Advanced, and then click General.
5. Click the Configuration Parameters button.
6. Select the Add Row button at the bottom of the Configuration Parameters dialog box.
7. Specify the name of the parameter (for example isolation.tools.copy.disable) and a value (such as true).
8. Click OK to return to the virtual machine’s Properties dialog box.
9. Click OK again to return to vSphere Client.
10. Power on the virtual machine.
Don’t Allow a Virtual Machine User or Process to Disconnect Devices
It’s a good idea in terms of security to prevent a user or process inside a virtual machine from being able to connect or disconnect devices such as the floppy, CD/DVD drive, or network adapter. Otherwise, an unprivileged guest OS user or process could potentially connect or disconnect these devices. Keep in mind that we are not talking about preventing a properly authorized user, using vSphere Client, from connecting or disconnecting devices. Instead, we are talking about preventing the connecting or disconnecting of devices from within the virtual machine and the guest operating system.
To make this change, add this configuration parameter to the virtual machine configuration file:
<device_name>.allowGuestConnectionControl = "false"
You can add this parameter to the VM configuration file using vSphere Client. Follow the procedure described in the previous section, “Disable Copy and Paste.” You’ll want to replace <device_name> with the name of the device, such as ethernet0 or floppy0.
Making this change ensures that only users granted the appropriate access within vCenter Server are able to connect or disconnect devices like the floppy drive, CD/DVD drive, or network adapter. Again, this change only affects the ability of users and processes within the virtual machine or guest operating system; it does not affect users operating upon the virtual machine using vSphere Client.
NOTE Along the same lines as preventing a user or process from connecting or disconnecting devices, you should also remove any unnecessary hardware components from the virtual machine. For example, if the virtual machine doesn’t need a floppy drive, you should remove the floppy drive from the virtual machine configuration.
Harden the Guest Operating System
It’s important to manage the security of the guest operating system within the virtual machine. Controls placed at the virtualization layer—such as access controls within vCenter Server—don’t translate into the appropriate security controls within the guest operating systems. Be sure to follow established best practices with regard to securing the guest operating systems found within the virtual machines. This includes applying all applicable security patches and updates, using firewalls where applicable, enforcing access controls within the guest OS, and exercising the principle of least privilege. The guest operating system vendors provide extensive resources with detailed recommendations on how to secure their specific products. We suggest that you refer to the recommendations from your guest OS vendors to secure the guest operating systems appropriately.