Setting permissions on vCenter objects_PowerCLI Cookbook-QQ阅读中文轻小说网

书名：PowerCLI Cookbook
作者名：Philip Sellers
本章字数：1244字
更新时间：2025-04-04 21:05:24

Setting permissions on vCenter objects

As a shared computing platform, vSphere has always had a strong roles and permissions model. This allows administrators who control the physical infrastructure and the virtual infrastructure to delegate levels of access to users. vCenter provides nine default roles that you can assign to users on different vSphere objects. By contrast, an ESXi host only has three default roles: Administrator, Read-Only, and No Access.

What is great about the vSphere permission model is that you can take users or groups (both AD, and from vSphere, SSO) and you can assign them a level of access at a cluster, folder, resource pool, datacenter, or at the vCenter root. The same user or group can have different access at different levels, but permissions assigned at a higher level are inherited through objects at lower levels in the hierarchy.

If you have specific needs, vCenter also exposes the ability to create your own roles using individual vSphere privileges. This allows very specific access to be granted for users and tighter security for all of the shared resources. There are hundreds of privileges that can control interaction for vCenter and each one can be configured into a custom role and assigned in vCenter.

In this recipe, you will learn the basic cmdlets used to assign roles and permissions to users and vSphere objects.

Getting ready

To begin, you will need to open a PowerCLI window and connect to a vCenter server.

For the purpose of this recipe, you will take our folder structure and assign groups of users from Active Directory to access these resources using predefined roles. This assumes that you have properly configured your VMware SSO to allow Active Directory authentication.

You will take an Active Directory group called IT Admins and delegate access to the entire Primary datacenter. You will take the Finance Developers group and delegate the operator access to them for the Finance folder in vCenter. You will delegate the read-only access to a service account user who is going to be reporting on vCenter using PowerCLI.

How to do it…

In order to set up permissions on vCenter objects, perform the following steps:

To begin, you will want to know what roles are available on the system where you can add permissions. To do this, you run the Get-VIRole cmdlet and pipe it to a Select cmdlet to return just the name and description:
```
Get-VIRole | Select Name, Description
```
Now that you have a list of roles to work with, you can begin the permission assignment. To do this, you will use the New-VIPermission cmdlet. This cmdlet requires an Entity where the permission will be applied, a Principal who represents the user or group and the desired role. For the first cmdlet, you will grant the Admin role on the Primary datacenter to our IT Admin group, which has the principal name DOMAIN\IT Admin:
```
New-VIPermission -Entity (Get-Datacenter "Primary") -Principal "DOMAIN\IT Admins" -Role Admin
```
Using the same format for another New-VIPermission cmdlet, you can now grant our Finance Developers group the operator status as VirtualMachineUser on the Finance folder. You will use the Get-Folder cmdlet to set our entity (or location):
```
New-VIPermission -Entity (Get-Folder "Finance") -Principal "DOMAIN\Finance Developers" -Role VirtualMachineUser
```
Lastly, you want to grant read-only access to the reports service account that will be used to script reports and/or perform monitoring on vCenter. You will again use the New-VIPermission cmdlet and the ReadOnly role granting access to the Primary datacenter:
```
New-VIPermission -Entity (Get-Datacenter "Primary") -Principal "DOMAIN\reports" -Role ReadOnly
```
For the next step, suppose you have some users that work at an IT Monitoring office, who need to be able to monitor vSphere and clear alarms on vCenter. There is no predefined role that has those specific permissions. However, with PowerCLI, you can create a new role. To begin, let's use the Get-VIRole cmdlet to retrieve the readonly role and view the privileges assigned:
```
Get-VIRole -Name readonly | Select Name, PrivilegeList
```
With this, you can see that the readonly role has three privileges –Anonymous, View, and Read. You can use these as the basis of our custom role. However, you need to give the user rights to clear alarms, so the next step is to find the privilege to do this. In order to find this, you can use the Get-VIPrivilege cmdlet to get a list of privileges related to alarms by searching with the help of the -Name parameter and a wildcard:
```
Get-VIPrivilege -Name *alarm*
```
With the output from the previous cmdlet, you can see a privilege called Acknowledge alarm that should allow our IT Monitoring group the access they need. The next step is to create our custom role. To do this, you use the New-VIRole cmdlet and pass in a name for our new role and the privileges you have found using the -Privilege parameter:
```
New-VIRole -Name "IT Monitoring" -Privilege "Anonymous", "View", "Read", "Acknowledge alarm"
```
Last but not least, you have to assign the permission using our new role. To do this, you use the New-VIPermission cmdlet again with the -Entity, -Principal, and -Role parameters:
```
New-VIPermission -Entity (Get-Datacenter "Primary") -Principal "DOMAIN\IT Monitoring Group" -Role "IT Monitoring"
```

How it works…

With the vSphere roles and permissions model, administrators have a very high level of control over what and where users can have access. The default roles can be easily leveraged to assign permissions for common sets of functionality. A role is a defined group of privileges that can be assigned to an individual user or group of users. Privileges are specific rights to perform granular tasks in vSphere. If a default role doesn't have the exact mix of privileges that you need to grant, vSphere is extensible, and a custom role can be created.

The second half of the model is the permissions. Permissions use defined roles along with user account or groups. From a cmdlet standpoint, the user account or groups are known as Principals. A permission consists of a role and a principal, and permissions are defined on particular objects. Permissions are inherited through the hierarchy, which means that if you grant a permission at the datacenter level, then all of the folders, clusters, hosts, virtual machines, networking, and datastores will inherit the permission granted at the datacenter level.

As you illustrated in the recipe, you can take individual folders that contain groups of VMs for a specific group of users and grant permissions for them. In our example, our Finance Developers group of users need operational privileges on the Finance folder of VMs. Using the default VirtualMachineUsers role, you can grant them access to do operations such as power on and power off the VMs, and use the remote console.

There's more…

With hundreds of privileges packaged with vCenter, it can be daunting to try and create custom roles. Some privileges that might not be obviously required can prevent a custom role from having the desired access. One suggestion is to take an existing or default role and then work from its privilege set to alter it for your uses. This can easily be done by retrieving an existing privilege set and storing them in a variable. Then you can pass this existing list of privileges into your new custom VIRole.

For many environments, the default roles can be absolutely sufficient for most administration. The other great advantage of using the default roles is that these change from version to version of vCenter as new privileges can be added.