Книга: Mastering VMware® Infrastructure3

Managing and Maintaining VirtualCenter Permissions

Managing and Maintaining VirtualCenter Permissions

The security model for VirtualCenter is identical to that explained in the previous section for an ESX Server: take a user or group and assign them to a role for a specific inventory object. The difference in the VirtualCenter security model is the origin of the user or group objects. In the VirtualCenter environment, the users and groups are actually Windows users and groups, but exactly which users will depend on whether your VirtualCenter server is a part of a domain or not. If the VirtualCenter server belongs to a workgroup, then the users and groups are stored in the local Security Accounts Manager (SAM) on that server and are managed through the Local Users and Groups node of the Computer Management snap-in. If the VirtualCenter server belongs to an Active Directory domain, then the users and groups available for assignment to roles are pulled from the Active Directory database and are managed through the Active Directory Users and Groups snap-in. This is fairly typical for a Windows server-based application, and also helps us to continue to manage all of the users in our network in one place: Active Directory. If you don't have the ability to create users and/or groups in Active Directory, you will need to make arrangements with your Active Directory administration team to assist you in that area. Once the users and/or groups are created, they will be available for you to assign roles to them through VirtualCenter. We will assume that the VirtualCenter environment is based on a server that is a part of an Active Directory domain for the purposes of this discussion, although the procedures for assigning permissions remains essentially the same if you have a workgroup-based installation. The key is to remember where to create the users and groups you need to use.

Real World Scenario

VirtualCenter in a Workgroup vs. VirtualCenter in a Domain

You can install VirtualCenter on a Windows Server 2003 system that belongs to a workgroup or a domain. Although the security model and configuration steps are identical in both cases, there are significant concerns that arise in both cases.

In most cases, you'll install VirtualCenter on a computer that belongs to a Windows Active Directory domain. Doing this means users and groups that are granted access will likely reside in the Active Directory database. It also means signing into a VirtualCenter will take place under the context of a domain account, which in turn means passwords for accessing VirtualCenter will be susceptible to the domain password policies in effect. Even though the account information is the same, VirtualCenter does not currently support any type of single sign-on method in which your existing credentials are passed to the application. You will still have to type your username and password for VirtualCenter access. From a management perspective, installing VirtualCenter on a domain member eliminates the need to manage multiple user accounts, but it does pose a security risk that must be addressed.

The default permissions in a VirtualCenter installation provide the local Administrators group of the VirtualCenter server with membership in the Administrator role at the root of the inventory. As you learned in the previous section, this role has all privileges for virtual infrastructure management. The problem with this is that the Domain Admins group is, by default, a member of the local Administrators group, thereby granting all Domain Admins complete rights in the VirtualCenter infrastructure. In most cases, this will violate the principle of least privilege as all Domain Admins are not necessarily qualified or hired to be virtual infrastructure administrators. To mitigate the risk involved with the default configuration, create a new Active Directory organizational unit (OU) that includes the user accounts and groups for the virtual infrastructure administrators. Then, change the Active Directory permissions to prevent the Domain Admins from managing the new OU.

As shown in this image, you can create and configure an Active Directory group to prevent Domain Admins from managing the group membership. This group can then replace the local Administrators group in the VirtualCenter root permissions list.

Once you've created the new group and granted it rights in VirtualCenter, you can remove the local Administrators permissions entry from the root of the VirtualCenter inventory, which will remove the original security concern. The following image shows how replacing local Administrators with a custom group eliminates a Domain Admin's ability to manage the virtual infrastructure:

 Alternatively, you can install VirtualCenter on a Windows Server 2003 system that belongs to a workgroup. As part of a workgroup, the Domain Admins will not have a default membership in the local Administrators group. The downside to the workgroup configuration is the multiuser account management now in place. Users accessing VirtualCenter will now use a completely different user account that is not susceptible to the domain password policies. 

VirtualCenter has a more structured hierarchy with greater depth than an ESX Server host. As outlined in the previous section, the only way to organize virtual machines on an individual ESX host is to build a resource pool, and then move the appropriate virtual machines into that resource pool. The VirtualCenter hierarchy opens opportunities to create folder structures for organizing objects like datacenters and virtual machines. 

In the VirtualCenter environment, start by creating, as a minimum, a datacenter. The datacenter object is the building block of a VirtualCenter hierarchy.

Perform the following steps to create a datacenter object:

1. Use the VI Client to connect to a VirtualCenter server.

2. Right-click the Hosts & Clusters root node in the inventory and select the New Datacenter option, as shown in Figure 8.17.

3. Type a name for the new datacenter object.

So what exactly is a datacenter object used for? A datacenter is used to organize ESX Server hosts, resource pools, virtual machines, and templates based on a company's management style. It is the building block of the VirtualCenter inventory, much like organizational units are the foundation of an Active Directory structure. An ESX host cannot be added directly to the VirtualCenter. A datacenter must exist in order to add an ESX Server. VirtualCenter is designed as an enterprise management application for all of the ESX servers in your worldwide organization. So the question remains: How do you manage resources? Is your management strategy based on geography, departments, or projects? Or do you prefer an arbitrary management style? In any case, Virtual-Center supports your style. Datacenters can be named by location, department, project, or can be given generic names like Datacenter1, Datacenter2, and so forth.

Figure 8.17 The Datacenter object is the building block of the VirtualCenter inventory.

Think about what would happen if you were to place every document in your computer at the root of your hard drive. Finding documents would be difficult to say the very least, and assigning permissions to objects would be similarly difficult. Thus would be the case if our virtual infrastructure objects (hosts, resource pools, virtual machines, templates) were all located in a flat structure under the root.

Take, for example, an organization with offices in St. Petersburg, Florida, and Los Angeles, California, where each office will have several ESX hosts and dozens of virtual machines and template objects. The infrastructure might be constructed so that the hosts in Los Angeles are attached to a shared storage device in Los Angeles, and the St. Petersburg ESX Server hosts are attached to a second shared storage device local to their site. Keep in mind that these servers will be able to talk to each other via a WAN connection, but they can only access storage in their specific region. In addition, if the company has an IT staff in each location, then the administrators will create logical datacenter objects based on physical location.

This example could just as easily have been detailed as a departmental-specific configuration in which the finance, marketing, and sales departments have their own respective ESX Server hosts. In this case, the logical datacenter objects would be labeled by department rather than physical location.

This organization also does one more thing: a datacenter is a boundary for the configuration of VMotion, HA, and DRS. In other words, you can only migrate a virtual machine with VMotion to another host in the same datacenter where it is currently running, in the same way that HA can only fail over to another host in the same datacenter. The VMotion, HA, and DRS topics will be covered in more detail in Chapters 9 and 10.

But what happens if there are 30 datacenters in your organization, some located in Europe, some in North America, some in South America — and all with different teams of administrators managing them? The simple answer is to create folders under the root object in VirtualCenter and then create (or move) your datacenter objects under those folders. Creating folders under the root and placing datacenter objects beneath them allows for broader access control management. Think about why you create folders on network drives: to organize files and other folders and to simplify the assignment of permissions to many objects. Designing a VirtualCenter inventory employs the same logic. Figure 8.18 details a VirtualCenter inventory where multiple datacenter objects exist beneath a folder structure that provides an additional layer of management and access control. In this case, the datacenters are managed by geography: East Coast or West Coast.

Figure 8.18 Folders created above the datacenter object offer flexibility in providing broader access control.

In the same way you can use folders to organize datacenters, you can also create folders within the datacenter to organize virtual machines according to your needs. For more detailed micromanaging scenarios, folders within folders can be created. Figure 8.19 details an inventory structure where datacenters are organized by geography and servers are managed by the rack in which they exist.

Figure 8.19 Creating folders beneath a datacenter provides more granular access control and management strategies.

As explained in the previous section, a special type of folder called a resource pool is used to organize virtual machines. The key difference between a regular folder and a resource pool is that a resource pool allows for the carving of CPU and memory resources to provide resource limitation to virtual machines within the pool. Resource pool functionality will be discussed with more detail in Chapter 9; for now, our focus is on the access control capabilities of the resource pool as an object in the inventory.

VirtualCenter offers two main views of the objects within the inventory: Hosts & Clusters and Virtual Machines & Templates. Until now we have remained in the default view of Hosts & Clusters, but the Virtual Machines & Templates view is extremely valuable for organizing virtual machines with respect to the management and access control needs of the traditional Windows administrators. The alternate views available in VirtualCenter maintain their own respective structures to support management of the various objects. For example, changes to objects in the Hosts & Clusters view does not necessarily result in changes to the objects in the Virtual Machines & Templates view. Figure 8.20 shows details of a Virtual Machines & Templates view constructed to support access control implementation based on the types of virtual machines in the infrastructure. The inventory is made up of several custom folders called Finance VMs, Medical System VMs, Infrastructure VMs, and the default Discovered Virtual Machine, which catches any unassigned virtual machines. These folders, like those in the Hosts & Clusters view, provide a boundary for assigning permissions.

Figure 8.20 The Virtual Machines & Templates view maintains its own hierarchical structure to enhance access control possibilities.

The remaining views in VirtualCenter, Networks and Datastores, though not more common utilities, provide consolidated looks at all the networks and datastores configured within the available datacenter objects. Figures 8.21 and 8.22 show examples of these views.

Figure 8.21 The Networks view provides a consolidated look at all the available networks and the virtual machines connected to each respective network.

Figure 8.22 The Datastores view provides a consolidated look at all datastores available in a datacenter as well as a summary of the datastore, the virtual machines it contains, and the hosts that have access.

Where the ESX Server host was quite limited in its default roles, VirtualCenter provides more default roles, thereby offering a much greater degree of flexibility in constructing access control. Although both security models offer the flexibility of creating custom roles, ESX Server included three default roles while VirtualCenter provides eight default roles, including the same three offered in ESX Server. Figure 8.23 details the default VirtualCenter roles.

Figure 8.23 The VirtualCenter default roles offer much more flexibility than an individual ESX Server.

As you can see, there are a large number of roles provided by VMware in a default Virtual-Center installation. Remember, just like the default ESX roles, it is considered a best practice to not modify the default roles provided by VMware. Editing the defaults could result in over- or under-assigning permissions. If the default roles are edited and other administrators are unaware of the alteration, the use of the default role results in unexpected privileges or a lack of any privileges. If you need a similar role to one that is a default, then clone that role and change the permissions assignment for the cloned role. The key to using these roles effectively is to understand the functions of each of the roles provided by VMware:

No Access This role is just what it sounds like — it permits a user or group no access. But why do we need it? The idea behind this role is 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. For instance, you may have granted Bob the Virtual Machine Administrator a role at the datacenter level, which would permit him to administer all of the virtual machines in the datacenter, but there is a security concern about him having access to one of the accounting virtual machines in that datacenter. You could assign Bob to the No Access role on the Accounting virtual machine, which would effectively supersede his Virtual Machine Administrator privileges.

Read-Only Read-Only allows users to see the VirtualCenter inventory. It does not allow them to interact with any of the virtual machines in any way through the VI Client or the web client except to see what the power status of each virtual machine is in the inventory where they have the Read-Only role applied.

Administrator A user assigned to an object with the Administrator role will have full administrative capabilities over that object in VirtualCenter. Note that this does not grant any Windows privileges. For instance, a user assigned the Administrator role for a virtual machine may be able to change the RAM assigned to the virtual machine and alter its performance parameters (Shares, Reservations, and Limits), but may not even have the permissions to log into that Windows virtual machine unless his or her Windows account has those permissions.

The Administrator role can be granted at any object level in the hierarchy and the user or group that is assigned the role at that level will have VirtualCenter administrative privileges over that object and (if the inheritance box is checked) any child objects in the hierarchy. This is in contrast to the Virtual Machine Administrator, who has limited privileges on certain inventory objects but full administrative capabilities over virtual machines.

Virtual Machine Administrator The VM Administrator role is used to assign full administrative privileges to a user or group, but only to virtual machines. The idea here is, as an example, if a user is granted the VM Administrator role at a datacenter level, he or she would only be able to fully administer virtual machines in that datacenter, but that user would not be able to change settings on objects such as resource pools in that datacenter.

Datacenter Administrator The Datacenter Administrator role is targeted at users whose primary function is to set up the infrastructure of the hosts, clusters, and networks within the Datacenter object. Interestingly enough, the Datacenter Administrator Role does not include the ability to create virtual machines, although the administrator can set up folders and resource pools for the virtual machines to be placed into.

Resource Pool Administrator The Resource Pool administrator is able to manage and configure resources with a resource pool including virtual machines, child pools, scheduled tasks, and alarms.

VMware Consolidated Backup User As the role name suggests, the VMware Consolidated Backup user has the privileges required for performing a backup of a virtual machine using VCB.

Virtual Machine Power User The VM Power User role grants a user the ability to interact with and change the configuration of an existing virtual machine. The VM Power User role is essentially a VM Administrator without the ability to create or delete a virtual machine. In addition, a user cannot move a virtual machine within the VirtualCenter hierarchy.

Virtual Machine User The Virtual Machine User role grants the user 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-ROM drive or floppy drive as long as they also have access to the media they wish to change. For instance, a user who is assigned this role for a virtual machine will be able to change the CD media from an ISO image on a shared storage volume to their own client system's physical CD-ROM drive. If you want them to have the ability to change from one ISO file to another (both stored on a Virtual Machine File System [VMFS] volume or Network File [NFS] volume), they will also need to be granted the Browse Datastore permission at the parent of the Datastore object in the VirtualCenter hierarchy — usually the datacenter that the ESX host is located in.

What if the roles listed here don't provide you with the necessary functionality for a particular grouping of users? Well, it depends on what the problem is. Let's take the most basic problem. You've chosen a best fit role to assign a user privileges, but you just want them to do one more thing — or perhaps it's that the role assigns too many privileges. For such cases, it is best to clone the existing role and make the minor adjustments.

Perform the following steps to clone a role in VirtualCenter:

1. Use the VI Client to connect to a VirtualCenter server.

2. Click the Admin button on the toolbar and then select the Roles tab.

3. Right-click on the role that is to be cloned and then click the Clone option, as shown in Figure 8.24.

Figure 8.24 Cloning an existing role provides a starting point for role customization.

Once you've cloned the role, you can add or remove privileges as needed.

That takes care of just tweaking a role for your own purposes, but what if a user needs permissions on two different objects in the inventory? The example we discussed previously is when the user needs to change the ISO image that's mounted in the CD-ROM drive of the virtual machine to a different ISO. A Virtual Machine User has access to the CD-ROM properties of a virtual machine, but they don't have access (by default) to browse the datastores where the ISO images are stored. In this case, you would perform two separate permissions assignments. First, you would assign the user to the VM User role directly on the virtual machine or on the folder in which the virtual machines are stored. Next, you would create a custom role, grant the Browse Datastore privilege to the role, and assign the user to the role. Last, you would assign the permission in the inventory.

Real World Scenario

Real World Scenario: VirtualCenter Permissions Interaction

In organizations, both large and small users will often belong to multiple groups, and those groups will be assigned different levels of permissions on different objects. Let's observe the effects of multiple group memberships and multiple permission assignments in the virtual infrastructure.

In the first scenario, we look at the effective permissions when a user belongs to multiple groups that have different permissions on objects at different levels in the inventory. In the example, a user named Rick Avsom is a member of the ResPoolAdmins and VMAuditors Windows groups. As shown in the next images, the ResPoolAdmins group is assigned membership in the Resource Pool Admins VirtualCenter role and the permission is set at the Production Resource Pool while the VMAuditors group is assigned membership in the Read-Only VirtualCenter role and the permission is set at the Win2008-02 virtual machine.

When logged on to the VirtualCenter server as Rick Avsom, the inventory will reflect only the objects available to him through his permissions application. Based on the permission assignment shown in the images above, Rick Avsom will be able to manage the Production resource pool and will have full privileges over the Win2008-01 virtual machine to which the Resource Pool Admin privileges are propagating. However, Rick Avsom will not be able to manage the Win2008-02 virtual machine to which he is limited to Read-Only privileges. The conclusion to this scenario is that users in multiple groups with conflicting permissions on objects lower in the inventory will be granted only the permissions configured directly on the object.

Another common scenario to understand is the effective permissions when a user belongs to multiple groups that have different permissions on the same objects. In this example, a user named Sue Rindlee is a member of the VMAdmins and VMAuditors Windows groups. The VMAdmins group has been assigned membership in the Virtual Machine Administrator VirtualCenter role while the VMAuditors group has been assigned membership in the Read-Only VirtualCenter role. As shown in the image here, both of these roles have been assigned permissions on the Production resource pool.

When logged on to the VirtualCenter Server as Sue Rindlee, the inventory will reflect only the objects available to her through her permissions application. Based on the permission assignment shown in the image, Sue Rindlee will be able to fully manage all of the virtual machines in the production resource pool. The image shown here validates that Sue's Virtual Machine Administrator status through membership in the VM Admin group prevails over the Read-Only status obtained through her membership in the VMAuditors group.

The conclusion to this scenario is that the effective permission is a cumulative permission when a user belongs to multiple groups with different permissions on the same object. Even if Sue Rindlee belonged to a group that had been assigned to the No Access VirtualCenter role, her Virtual Machine Administrator role would prevail. However, if Sue Rindlee's user account was added directly to a VirtualCenter object and assigned the No Access role, as shown in this image, then she would not have access to any of the objects to which that permission has propagated, as shown in the next image.

 

Even with a good understanding of permission propagation, you should always proceed with caution and always maintain the principle of least privilege to ensure that no user has been extended privileges beyond those that are needed as part of a job role. 

Roles are very useful, but now that we've started to peek into the properties of the roles, we should take a look at what each of the privileges are and what they do for you in terms of customizing roles. Remember that privileges are individual tasks that are assigned to roles. This is a rather long list of privileges, but it's broken down into some general categories, so we'll begin by looking at what each of the categories means in general terms: 

Global Includes the ability to manage VirtualCenter license settings and server settings like SNMP and SMTP.

Folder Controls the creation, deletion, and general manipulation of folders in the Virtual-Center hierarchy.

Datacenter Controls the ability to create, delete, move, and rename datacenters inside VirtualCenter.

Datastore Controls who can access files stored on an ESX attached volume. This permission needs to be assigned at the parent object of the ESX host itself — for instance, a datacenter, an ESX cluster, or a folder that contains ESX hosts.

Network Controls the removal of networks from the VirtualCenter inventory.

Host Controls what users can do with the ESX host itself in inventory. This includes tasks like adding and removing ESX hosts from the inventory, changing the host's memory configuration, or changing the Service Console firewall setting's network configuration. 

Virtual Machine Controls the manipulation of Virtual machines in the VirtualCenter inventory, including the ability to create, delete, or connect to the remote console of a virtual machine, to control the power state of a virtual machine, to change floppy and CD media, and to manipulate templates among other privileges.

Resource Controls resource pool manipulation, including creating, deleting, or renaming the pool itself, and controls migration by using VMotion and applying DRS recommendations.

Alarms Controls the configuration of alarms in the VirtualCenter hierarchy.

Scheduled Task Controls the configuration of tasks and the ability to run a task that is scheduled inside VirtualCenter.

Sessions Controls the ability to view and disconnect VI Client sessions connected to VirtualCenter and to send a global message to connected VI client users. As shown in Figure 8.25, a user without Sessions privileges cannot terminate VI Client sessions.

Figure 8.25 Session Control in VirtualCenter allows a user to disconnect VI Client sessions.

Performance Controls the ability of users to modify the intervals at which the performance chart information is displayed on the performance tab of an object.

Permissions Controls who has the ability to modify the permissions assigned to a role and who can manipulate a role/user combination for a particular object.

Extensions Controls the ability to register, update, or unregister extension in VirtualCenter. The two existing extensions include VMware Update Manager and VMware Converter.

VMware Update Manager Controls who has the ability to manage system baselines and updates as well as configure the VMware Update Manager service.

Table 8.1 details the default privileges assigned to each of the VirtualCenter roles.

Table 8.1: Table of Privileges for Default Roles

Manage your permissions carefully. Do not provide more permissions than are necessary for the job role at hand. It is always better to err on the side of caution when it comes to delegating authority. Just as in any other information systems environment, your access control implementation will be a living object that will consistently require consideration and revision. Be flexible, and expect that users and administrators alike are going to be curious and will push their access levels to the limits. Stay a step ahead and always remember the principle of least privilege.

Оглавление книги