Solutions provider takeaway: In vSphere environments, problems can arise from assigning security access controls incorrectly. To preempt these problems, solutions providers should scrutinize each layer of the environment to determine proper access levels for users. An expert outlines how to assign privileges, roles and permissions to ensure solid vSphere security.
Security is critical in a vSphere environment. Virtual machine (VM) architecture, access methods and management is much different from that for physical servers. Because VMs are encapsulated into a single file that resides on a shared data store, additional attack vectors need to be secured. Further, any change or operation in a virtual environment can have a ripple effect on other residing VMs because all share common infrastructure components. Consequently, having proper security access controls in place is paramount to protect hosts and their VMs.
Because they have multiple components, virtual environments are secured in layers. You can do much of the work to secure an environment through vCenter Server, which provides centralized authentication and authorization services at many different levels inside vSphere. VCenter Server features four main components:
- Privileges. A privilege enables or denies users access to perform actions in vSphere.
- Roles. A role is a set of privileges that can be assigned to a user or group.
- Users and groups. Users and groups are used in permissions to assign roles from Active Directory (AD) or local Windows users/groups.
- Permissions. A permission is assigned to an object in vSphere and is composed of users/groups and a role.
Viewing and choosing privileges for vSphere security
Privileges are divided into some 20 categories and subcategories. Figure 1 displays a high-level view of most of the main privilege categories that are available in vSphere.
Figure 1: A high-level view of privileges in vSphere
When you expand the categories, you can see subcategories and individual privileges beneath them (see Figure 2).
Figure 2: Expanding categories enables you to see subhcategories
Solutions providers can view privileges only when creating or modifying roles. Selecting the Virtual Machine category includes all the subcategories and privileges within it. If you want to get more granular, you can uncheck the items under your selected category to grant the desired privileges.
Many privileges can be assigned, especially on a host and a VM. Some vCenter Server actions require that multiple privileges be assigned to complete an action. Many privileges are self-explanatory, but determining which ones are needed for specific actions can be confusing. One option is to mix and match privileges by creating a test user account and then assigning and removing privileges. You can then log in as that user and see whether you can complete the action. If you cannot, add a privilege back in and try again. It can be helpful to select a full category of privileges and then remove privileges one by one until you achieve the desired permission level.
Configuring and assigning roles
R oles can be customized to include or exclude any of the privileges in vCenter Server. VCenter Server comes with preconfigured roles, and you can customize roles as well. These roles fall into two categories: (1) system roles, which are permanent and cannot be deleted or changed; and (2) sample roles, which are configured for certain types of access and can be modified and deleted. To access roles, select Administration in vCenter Server and then select Roles, as shown in the Figure 3 below.
Figure 3: Accessing roles in vSphere
The Roles tab shows a list of configured roles. When you click on a role, it indicates the users that are associated with the role and their level of assigned access. When you create new roles, you can add, rename, remove, edit and clone roles. This functionality allows you to copy an existing role and modify it rather than create a role from scratch.
Selecting users and groups from AD or local domain
Users and groups can come from an AD domain or from accounts created locally on the vCenter Server. If a vCenter Server is a member of an AD domain, users and groups are automatically pulled from it. When you create a permission, user and group objects are assigned, and you can select multiple users/groups from a domain or local server (see Figure 4).
Figure 4: Selecting users and groups
Some Active Directory-related settings in vCenter Server require special attention. They are accessed under Administration ->vCenter Server Settings-> Active Directory (see Figure 5).
Figure 5: Accessing Active Directory settings in vSphere
These settings give you greater flexibility. If AD servers are on wide area networks, for example, you can increase timeout settings. If you have a large AD domain with many group and user objects, you can increase the query limit. The validation section ensures that users and groups are still valid in Active Directory. By default, vCenter Server validates all users and groups that are used in permissions on its objects once a day and ensures that they still exist in AD. If they don't, permissions are automatically deleted.
VCenter Server does not use the security identifiers (SIDs) that are long strings of letters and numbers used by Windows to uniquely identify users. If an account is deleted in AD and re-created with the same name, it has a different SID in Windows and won't have access to its previous Windows permissions. But vCenter Server, will consider this as the same account and have the same permissions because it uses only the domain and username of the user instead of the SID.
You can disable this feature entirely and change the interval from the default of 1,440 minutes (or one day). If you are concerned about security in your customer's environment, reduce the validation period (i.e., 120 minutes). This practice isn't recommended, however; the feature protects vCenter Server by automatically removing invalid permissions.
Assigning permissions to specific objects, users
Permissions allow you to assign privileges to users or groups to perform certain actions and make changes to objects inside vCenter Server. VCenter Server permissions affect only those users who log into vCenter Server rather than users who log into an ESX host directly.
Permissions are quite granular, and dozens can be assigned to control access to the various objects inside vCenter Server. They can be set on different levels as well: from the highest data center level down to an individual VM.
You can view permissions by selecting an object in vCenter Server (i.e., a host) and then the Permissions tab in the right-hand pane. You will see the user/group, the role assigned to it and the level at which it was set. If a permission has been set at a higher object level, you can delete it only by selecting the defined object. You can control whether permissions propagate from their set level down to other objects in the hierarchy. You can also set multiple permissions for a user or group to control access levels for different levels of objects inside VC. You can grant a user read access at the top data center level, for example, so he can read all objects in the data center but set higher access to certain specific objects such as ESX hosts or VMs.
Roles allow you to create a set of privileges as a role that you can assign to a user and group. You cannot assign privileges directly to a user or group but must instead assign privileges to a role and then assign a user to that role. Users can be assigned multiple roles with different privileges on different objects in vCenter Server. But if a user has different levels of permissions on the same object, the most restrictive permissions apply. If a user has read-only permission on a host and also full administrator permissions, his permissions default to read only. You can set permissions by selecting the desired object and selecting the Permissions tab in the right-hand pane and right-clicking and selecting Add Permission. You can then select users and groups and a single role (see Figure 6).
Figure 6: Assigning privileges to a user or group
Note that when you select multiple users and groups in creating permissions, the Permissions tab displays these users or groups individually. If a user is assigned to a role that is granted privileges on an object (i.e., an ESX host), a user can see all information on that object but have permission to perform only those actions on the object that have been privileged. If a user lacks permissions for that action, many of the actions that a full administrator can see are masked or grayed out.
Additionally, if you apply permissions at a low level of a hierarchy (i.e., a VM), users will not see other objects (e.g., VMs) for which they lack permissions to view (unless permissions have been specifically applied to a higher level). When you assign a user permission to manage only a specific VM when he logs into vCenter Server, they will only see the datacenter object and that VM. They will not see any other VMs, the ESX host that the VM is on, Clusters, Resource Pools, etc.
Permissions are a great way to assign access inside vCenter Server and should be used to ensure that unnecessary access is not assigned to vCenter Server users. Here are some best practices for using permissions:
- Certain privileges can be harmful to hosts and should be assigned to users only when required. This includes any privilege that allow a user to delete, rename, remove or create items that can cause data loss or data stores to be filled up. This can cause a denial of service attack on your VMs (i.e., prevent snapshot creation).
- Never assign more permissions to a user than needed. Assign permissions at the required level and avoid assigning them at the highest level. If a developer needs access to only one or two VMs on a host, assign permissions only at the specific VM level to which he needs access.
- Create roles that are customized to a user's requirements. To create a role for an operations team that is responsible for monitoring VMs, create one that allows VM interactions only (i.e., power on, power off, reset and console interaction). This allows team members to look at the console of a VM to see what is happening and power-cycle a VM.
- A privilege that should be assigned sparingly is the data store low-level file operations privilege, which allows users to upload and download files to a host data store. This privilege can create a security risk.
- More potentially dangerous privileges are in the network and distributed vSwitch categories, which can allow a user to move a VM to any available virtual LAN that is configured on your vSwitches. This can be particularly risky if you have public and private network vSwitches on a host where you definitely do not want a VM moved between them or connected to both at the same time. Assigning the network privileges to your network admins and denying them to everyone else is a good practice.
Now you now know how to use vCenter Server to secure customers' environments, but you also need to secure access to ESX & ESXi hosts when users connect directly to them with the vSphere Client or with the ESX service console. Limit this type of access as much as possible and grant access only when absolutely needed. Don't divulge the root-account password, and create separate local user accounts instead. These accounts are managed individually by connecting to each host, but the next update to vSphere will allow you to use Active Directory for this task.
VSphere includes great built-in security controls, so understand and fully utilize them to ensure your virtual environment remains safe and secure.
About the expert
Eric Siebert is a 25-year IT veteran whose primary focus is VMware virtualization and Windows server administration. He is one of the 300 vExperts named by VMware Inc. for 2009. He is the author of the book VI3 Implementation and Administration and a frequent TechTarget contributor. In addition, he maintains vSphere-land.com, a VMware information site.