Chris McCain - Mastering VMware® Infrastructure3

5 inventory.</p> <div class="title"> <p>Chapter 8</p> <p>Configuring and Managing Virtual Infrastructure Access Controls</p> </div> <p>As indicated in the introduction to Chapter 5, centralizing management of the sheer number of virtual machines and their ESX hosts has become an issue in most growing datacenters. Delegating control to the appropriate users so they can assist in managing the virtual infrastructure is also a large part of the centralized management model. For instance, how do you assign permissions to a group of users responsible for setting up virtual machines to test a new application? They might need to create the virtual machine and manage its access to resources, but they may need to be restricted in what they can do in other areas of the virtual infrastructure.</p> <p>Permissions to a virtual infrastructure can be managed through a VirtualCenter server or directly through an ESX Server host.</p> <p>In this chapter you will learn to:</p> <p>Manage and maintain ESX Server permissions Manage and maintain VirtualCenter permissions Manage virtual machines using the web console</p> <div class="title"> <p>Managing and Maintaining ESX Server Permissions</p> </div> <p>Both the VirtualCenter Server and the ESX Server use the same structured security model to grant users the ability to manage portions of the virtual infrastructure. As shown in Figure 8.1, this model consists of users (groups), roles, privileges, and permissions.</p> <p>The items that differ between the non-VirtualCenter environment and the VirtualCenter environment are predominantly in two areas:</p> <p>♦ The location of the user and group objects created</p> <p>♦ The level of granularity of the roles and privileges available in each environment</p> <p>For environments that don't have VirtualCenter, or where the administrator chooses to have users authenticate directly to the ESX Server to perform management tasks, it is important to start with a discussion of the security model.</p> <p>Permissions to an ESX Server host are assigned to Linux-based users and groups that exist in the Service Console. Perform the following steps to view the ESX Server users and groups:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Select the host in the inventory panel and then click the Users & Groups tab, as shown in Figure 8.2.</p> <img src=#i_276.png" > <p> <strong>Figure 8.1</strong>VI3 security model for assigning access control</p> <empty-line > <img src=#i_277.png" > <p> <strong>Figure 8.2</strong>ESX users and groups are stored in the Service Console.</p> <empty-line > <p>When constructing a virtual infrastructure, it is important from a security standpoint to identify who in your organization needs access to your ESX host to perform any level of management, using either an SSH connection (like Putty, WinSCP, FastSCP, etc.), the VI Client, and/or the web interface that we will discuss later in this chapter. The root username and password should be distributed with caution. If you determine that multiple users should be allowed direct access to an ESX Server host, provide each user with their own user account.</p> <p>As mentioned in the introduction, the VI3 and ESX Server security model are composed of users (or groups), roles, privileges, and permissions. In its most basic format, users or groups are assigned to a role that has privileges. The user-role-privilege combination is then associated with an object in the inventory as a permission.</p> <p>There are two buttons on the Users & Groups tab, the Users button and the Groups button, as shown in Figure 8.2. Users and groups — or at least the groups — are created in order to assign the group to the appropriate role. So what exactly is a role?</p> <p>ESX Server permissions are set up to help simplify assignment. Rather than choose the individual privilege to be assigned each time you need to delegate, you assign a user or group to a role. Then, the role is granted role a privilege or group of privileges. As shown in Figure 8.3, the Service Console houses three default roles: No Access, Read-only, and Administrator.</p> <img src=#i_278.png" > <p> <strong>Figure 8.3</strong>The Service Console includes default roles for assigning capabilities on an ESX Server host.</p> <empty-line > <p>The No Access role works as the name suggests. This role prevents access to an object or objects in the inventory. The No Access role can be used if a user was granted access higher up in the inventory. The No Access role can also be used at lower-level objects to prevent object access. For example, if a user is granted permissions at the ESX Server host but should be prevented access to a specific virtual machine, use the No Access role.</p> <p>Read-Only allows a user to see the objects within the VI Client inventory. It does not allow the user to interact with any of the visible objects in any way. For example, a user with the Read-Only permission would be able to see a list of virtual machines in the inventory but could not act on any of them.</p> <p>The Administrator role by nature has the utmost authority, but it is only a role, and it needs to be assigned using a combination of a user or group object and an inventory object like a virtual machine.</p> <p>With only three built-in roles in the Service Console, the defaults don't leave room for much flexibility. However, don't let that slow you down. The limits of the default roles are easily overcome by creating custom roles. You can create custom roles that will better suit your needs, or you can clone existing roles to make additional roles to modify for your own purposes.</p> <p>The default roles should not be modified. If a role does not suit the management needs, create a custom role. If you alter a default role, it may present a scenario where other administrators unknowingly grant too much or too little permission by assigning membership in a default role.</p> <cite> <div class="title">Default ESX Server Permission Assignments</div> <p>By default, when ESX is installed the only user that exists is the root user, and root has full administrative permissions to the entire server, as shown in this image:</p> <p> <img src=#i_279.png" > </p> <p>This default set of permissions changes when an ESX Server is managed by VirtualCenter. The process of adding a host to VirtualCenter adds an agent (the VirtualCenter Agent) and an additional Service Console account called vpxuser. The vpxuser account has a 32-character, complex, and randomly generated password that is also granted membership in the Administrator role on an ESX Server host. This assignment enables the VirtualCenter service to carry out tasks on the ESX hosts in the inventory.</p> </cite> <p>For example, assume that a set of users needs to interact with the console of a virtual machine, and also needs to change the CD and floppy media of those virtual machines. In the following steps, you'll create a custom role named VMusers: </p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Click the Admin button from the menu bar.</p> <p>3. Ensure the Roles tab is selected and click the Add Role button.</p> <p>4. Type the name of the new role in the Enter Name text box (in this example, VMUsers) and then select the privileges that will be required by members of the role, as shown in Figure 8.4.</p> <p>5. Click OK to complete the custom role creation. </p> <cite> <div class="title">Permissions for Changing Virtual Media </div> <p>To change floppy and CD media using FLP and ISO images that are stored on a SAN volume, you will also need to grant that group browse datastore privileges at the root of the hierarchy — in this case, at the ESX host itself.Читать дальше