VMware Infrastructure Security and Web Access

With great power comes great responsibility. Your responsibility is to make sure that the virtual infrastructure you have deployed is secure and that role-based access has been implemented so that the right users have the necessary security permissions to perform their daily tasks. This chapter is dedicated to security in VMware Infrastructure.

VI Security Model

The VMware Infrastructure security model consists of both VirtualCenter security and ESX Server security. The security model revolves around users and groups that are assigned roles. These roles constitute a collection of rights or privileges to perform certain tasks.

Users, Roles, Privileges, and Permissions

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:

• User and group: An account that is allowed to log in to the VMware infrastructure. A group is a collection of accounts with rights to log in and perform other tasks within the VMware Infrastructure.
• Role: A collection of privileges that a user or group is allowed to perform.
• Privilege: An allowed action or function within a role. In other words, a privilege allows a user or group to perform a certain task.
• Permission: A right assigned to an object in the inventory and grants a user or group the right to interact with that object according to selected roles and privileges.

Working with Roles

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.

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.

Assigning Permissions

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.

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 Security

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:

• Local: If VirtualCenter is installed on a Windows server that is part of a workgroup, the users and groups that are local members of this server can be configured to have access in VirtualCenter.
• Domain: If VirtualCenter is part of an Active Directory domain, in addition to the ability to configure local users and groups, you can also configure users and groups from Active Directory.

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.

ESX Server Security

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:

• root is the equivalent of the administrator in the Windows world and is the highest user account that is created by default.
• vpxuser is added to the Administrators group in ESX after the ESX Server is joined to VirtualCenter. VirtualCenter uses this user to authenticate itself to the ESX host to send preapproved commands.

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.