Chris McCain - Mastering VMware® Infrastructure3

</p> </cite> <img src=#i_280.png" > <p> <strong>Figure 8.4</strong>Custom roles strengthen management capabilities and add flexibility to permission delegations.</p> <empty-line > <p>As simple and useful as roles are, they are not functional until a user or group is assigned to the role, and then the role is assigned to an inventory object. Assume that a group of users exists that needs to interact with all virtual machines that are web servers. If access control is managed through the ESX Server, then you have to create a user account in the Service Console along with a new group — for example, SiteOperators. Once you've created these Linux-based users and groups, you can execute the security model. Follow these steps to grant virtual machine access control to a Service Console user or group:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Right-click the object in the inventory to which permission should be assigned and click the Add Permission option, as shown in Figure 8.5.</p> <img src=#i_281.png" > <p> <strong>Figure 8.5</strong>Granting access control begins with selecting the inventory object to which access must be granted.</p> <empty-line > <p>3. Click the Add button in the Assign Permissions dialog box, as shown in Figure 8.6.</p> <img src=#i_282.png" > <p> <strong>Figure 8.6</strong>The Assign Permissions dialog box allows you to select a user or group and associate it with an ESX Server role.</p> <empty-line > <p>4. Select the appropriate user or group (in this case, SiteOperators) and then click the Add button, as shown in Figure 8.7.</p> <p>5. Select the role that the Service Console users or groups should belong to, as shown in Figure 8.8.</p> <img src=#i_283.png" > <p> <strong>Figure 8.7</strong>Service console users and groups can be granted access to inventory objects. </p> <empty-line > <img src=#i_284.png" > <p> <strong>Figure 8.8</strong>The selection of a role ultimately dictates the privilege level a user or group has on an object.</p> <empty-line > <p>What if you have an ESX Server that will host 30 virtual machines and 10 of those are the web server virtual machines? As previously demonstrated, this approach then requires that you assign permissions on each of the ten web server virtual machines. This is not an efficient process. Further growth resulting in more web server virtual machines would require additional administrative effort to ensure access control. When creating a role, you'll notice an option, Propagate to Child Objects, that you can use to facilitate access control implementation. This option works like the inheritance settings in a Windows file system. It allows the privileges assigned in this role to be applied to objects beneath the selected object. For example, if the VMUsers role is applied as a permission on the ESX Server host in the inventory panel, and the Propagate to Child Objects option is enabled, all members of the VMusers role could interact with all the virtual machines hosted on the ESX Server. While this certainly simplifies access control implementation, it adds another problem: the permissions of the VMUsers role has been overextended and now applies to all virtual machines and not just the web server. With access control granted at the host level, VMUsers will be able to change floppy and CD media and use the console of the web server virtual machines, but they will also be able to do that on any other virtual machine in the inventory.</p> <p>This issue presents one of the drawbacks of managing access control on an individual ESX Server host. Keep in mind as well that all of the steps we have discussed so far would have to be performed on each ESX Server in the virtual infrastructure. What if there was a way to organize the inventory of virtual machines? In other words, what if we could create an object for the web server virtual machines and put all of the web server virtual machines within that object? Then we could assign the group to the role at the parent object level and let inheritance take over. As shown in Figure 8.9, the problem is that folder objects are not possible on a single ESX Server host.</p> <img src=#i_285.png" > <p> <strong>Figure 8.9</strong>Folder objects cannot be added to an individual ESX Server, leaving resource pools as the only viable solution for organizing virtual machines.</p> <empty-line > <p>A resource pool is actually a special object, a folder of sorts, that we will discuss in the next chapter in great detail, but the good news is that it will also help to organize our virtual machines. One byproduct of the resource pool is the ability to manipulate and manage many virtual machines as objects within the logical resource pool object.</p> <p>Perform the following steps to create a resource pool:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Right-click the hostname and select New Resource Pool, as shown in Figure 8.10.</p> <p>3. Type a resource pool name in the Name text box, in this case WebServers, as shown in Figure 8.10.</p> <img src=#i_286.png" > <p> <strong>Figure 8.10</strong>Resource pools provide a means of allocating resources as well as organizing virtual machines.</p> <empty-line > <p>4. Configure the resource allocations if desired to establish limits and reservations for the resource pool. The limit will establish a hard cap on the resource usage while the reservations establish a resource guarantee.</p> <p>5. Click OK.</p> <p>So now that we've created a WebServers resource pool, virtual machines can be placed under the resource pool, as shown in Figure 8.11.</p> <img src=#i_287.png" > <p> <strong>Figure 8.11</strong>Virtual machines can be placed into resource pools for resource management purposes.</p> <empty-line > <p>Resource pools become inventory objects to which permissions can be assigned, as shown in Figure 8.12.</p> <img src=#i_288.png" > <p> <strong>Figure 8.12</strong>As an object in the inventory, resource pools are potential levels of infrastructure management.</p> <empty-line > <p>Permissions can be removed from inventory objects when management needs change or when improper assignments have been made. In the previous example, the inappropriate permission previously applied to the host itself should be removed now that more appropriate permissions have been configured at the resource pool object.</p> <p>Use the following steps to remove permissions on an object in the inventory:</p> <p>1. Use the VI Client to connect to an ESX Server host.</p> <p>2. Select the object in the inventory and then select the Permissions tab.</p> <p>3. Right-click the permissions entry to be deleted from the list of existing permissions and then click the Delete option, as shown in Figure 8.13.</p> <img src=#i_289.png" > <p> <strong>Figure 8.13</strong>Permissions are removed from inventory objects as easily as they are added.</p> <empty-line > <p>You should see a warning indicating that users may retain their permissions because of an assignment higher in the hierarchy; however, in this case, that is what we are trying to accomplish. We want the users to have access to the virtual machines as a result of permissions applied at the resource pool, not the ESX Server.</p> <p>Once permissions have been assigned throughout the inventory, it is easy to lose track of what has been previously been done.Читать дальше