The cornerstones of the VMware Infrastructure (VI) security model are the users, groups, roles, privileges, and permissions that you can assign at different levels and to different objects within your infrastructure. Properly configuring and assigning these rights and permissions enables you to enforce accountability. Taking a closer look at each of these cornerstones helps you better design your security solution:

Familiarizing yourself with roles is an imperative task of building your access control into the Virtual Infrastructure. To help you get started, Table 8.1 shows a set of default roles available to you.

Table 8.1. Default Roles

The easiest way to get to the Roles panel is to log in to ESX Server or VirtualCenter using your VI client. Click the Administration tab and then the Roles tab, as shown in Figure 8.1.

Figure 8.1. Roles panel.

On the Roles panel, you can right-click any role and edit it. However, we recommend that you maintain the integrity of the existing roles and create your own custom roles if the need arises. To do so, you can right-click anywhere in the Roles pane and click Add to start the new role creation, as shown in Figure 8.2.

NOTE

Custom roles cannot be shared between ESX Server and VirtualCenter.

Figure 8.2. Add new role.

After you have crafted the appropriate roles for your environment, it is time to apply them to the right inventory object to allow your users and groups access only to the part of the inventory tree that you want them to have access to. To apply permissions, find the object in the tree on which you want to implement security, right-click it, and select Add Permission. This brings you to a screen similar to the one shown in Figure 8.3 that allows you to choose a user or group and assign the corresponding role that you want the user or group to have for this inventory object.

Figure 8.3. Assign permissions.

When assigning permissions, you may choose to have these permissions propagate from the object where the permission originated and downward to all the child objects. To do this, simply place a check mark in the check box next to Propagate to Child Objects, as shown in Figure 8.3.

If a conflict arises when assigning permissions, the most restrictive of the permissions takes precedence. For instance, if a user is part of a group in the Administrator role but the user is explicitly assigned a Read-Only role on a particular object, the most restrictive of the permissions takes precedence, thereby allowing the user only Read-Only permissions to the object. Keep in mind though that if permissions do not propagate down to any child objects, the user has Read-Only permission over the object but has full permissions over the child objects. The reason behind this is Propagate permissions is not enabled, which means you are slapping explicit permissions on this object only, but not its child object. The child objects in this case inherit the permissions given to the user’s group.

When explicitly assigned, permissions take precedence and the most restrictive permissions are enforced.

VirtualCenter is a Windows-based application to be installed on a Windows-based operating system. It has two types of directory repositories to select from:

By default, the local Administrators group is assigned the Administrator role at the top of the inventory list in VirtualCenter. If the VC server is member of a domain, the Domain Admins group is also added by default.

The ESX Server security revolves around the Service Console, and because the Service Console operating system is based on Red Hat Linux, the users and groups that you find in the ESX Server are Linux users and groups. These users and groups can be configured to grant direct access to an ESX host.

By default, the following users are assigned the Administrator role in ESX Server:

While the vpxuser is used to authenticate VirtualCenter to ESX Server and pass preapproved commands, the root account actually executes these commands. So in this case, the vpxuser acts merely as a secure bridge between VirtualCenter and the ESX host, while the root user account is tasked with executing VirtualCenter tasks.

The minimum system requirements to successfully connect and log in to Web Access are as follows:

On a Windows machine:

On a Linux machine:

One of the very cool things you can do with Web Access is to generate a regular web URL to a particular virtual machine. This URL gives you or any user you send it to direct access to this virtual machine. This capability is useful when you want to provide someone access to a virtual machine directly; you can just as easily paste the URL link into an email and send it to that person.

To generate a URL for a VM, you can simply click the Generate Remote Console URL link shown in Figure 8.4. This brings you to a screen similar to the one shown in Figure 8.5 that allows you to configure different settings to control which user interface features the user has access to.

Figure 8.5. Generate Remote Console URL window.