Section 1: Configure and Administer vSphere 6.x Security
Objective 1.1: Configure and Administer Role-based Access Control
Users, and roles control who has access to vSphere components and what actions each user can perform. A role is a predefined set of privileges. Privileges define rights to perform actions and read properties. For example, the Virtual Machine Administrator role consists of read properties and of a set of rights to perform actions. The role allows a user to read and change virtual machine attributes. When you assign permissions, you pair a user or group with a role and associate that pairing with an inventory object. A single user or group can have different roles for different objects in the inventory.
Compare and contrast propagated and explicit permission assignments
see Hierarchical Inheritance of Permissions below
View/Sort/Export user and group lists
You can view, sort, and export lists of a host’s local users to a file that is in HTML, XML, Microsoft Excel, or CSV format.
Procedure
1. Log in to ESXi using the vSphere Client.
2. Click the Local Users & Groups tab and click Users .
3. Determine how to sort the table, and hide or show columns according to the information you want to see in the exported file.
■ To sort the table by any of the columns, click the column heading.
■ To show or hide columns, right-click any of the column headings and select or deselect the name of the column to hide.
■ To show or hide columns, right-click any of the column headings and select or deselect the name of the column to hide.
4. Right-click anywhere in the table and click Export List to open the Save As dialog box.
5. Select a path and enter a filename.
6. Select the file type and click OK.
Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects
A permission is set on an object in the vCenter object hierarchy. Each permission associates the object with a group or user and the group’s or user’s access roles. For example, you can select a virtual machine object, add one permission that gives the ReadOnly role to Group 1, and add a second permission that gives the Administrator role to User 2.
By assigning a different role to a group of users on different objects, you control the tasks that those users can perform in your vSphere environment. For example, to allow a group to configure memory for the host, select that host and add a permission that grants a role to that group that includes the Host.Configuration.Memory Configurationprivilege.
To manage permissions from the vSphere Web Client, you need to understand the following concepts:
Permissions
Each object in the vCenter Server object hierarchy has associated permissions. Each permission specifies for one group or user which privileges that group or user has on the object.
Users and Groups
On vCenter Server systems, you can assign privileges only to authenticated users or groups of authenticated users. Users are authenticated through vCenter Single Sign-On. The users and groups must be defined in the identity source that vCenter Single Sign-On is using to authenticate. Define users and groups using the tools in your identity source, for example, Active Directory.
Roles
Roles allow you to assign permissions on an object based on a typical set of tasks that users perform. Default roles, such as Administrator, are predefined onvCenter Server and cannot be changed. Other roles, such as Resource Pool Administrator, are predefined sample roles. You can create custom roles either from scratch or by cloning and modifying sample roles.
Privileges
Privileges are fine-grained access controls. You can group those privileges into roles, that you can then map to users or groups.
Change Permissions
After a user or group and role pair is set for an inventory object, you can change the role paired with the user or group or change the setting of the Propagate check box. You can also remove the permission setting.
Procedure
- Browse to the object in the vSphere Web Client object navigator.
- Click the Manage tab and select Permissions.
- Click the line item to select the user or group and role pair.
- Click Change role on permission.
- Select a role for the user or group from the Assigned Role drop-down menu.
- To propagate the privileges to the children of the assigned inventory object, click the Propagate check box and click OK.
Add a Permission to an Inventory Object
After you create users and groups and define roles, you must assign the users and groups and their roles to the relevant inventory objects. You can assign the same permissions to multiple objects simultaneously by moving the objects into a folder and setting the permissions on the folder.
When you assign permissions from the vSphere Web Client, user and group names must match Active Directory precisely, including case. If you upgraded from earlier versions of vSphere, check for case inconsistencies if you experience problems with groups.
Prerequisites
On the object whose permissions you want to modify, you must have a role that includes the Permissions.Modify permission privilege.
Procedure
- Browse to the object for which you want to assign permissions in the vSphere Web Client object navigator.
- Click the Manage tab and select Permissions.
- Click the Add icon, and click Add.
- Identify the user or group that will have the privileges defined by the selected role.
- From the Domain drop-down menu, select the domain where the user or group is located.
- Type a name in the Search box or select a name from the list. The system searches user names, group names, and descriptions.
- Select the user or group and click Add. The name is added to either the Users or Groups list.
- (Optional) Click Check Names to verify that the user or group exists in the identity source.
- Click OK.
- Select a role from the Assigned Role drop-down menu. The roles that are assigned to the object appear in the menu. The privileges contained in the role are listed in the section below the role title.
- (Optional) To limit propagation, deselect the Propagate to Child Objects check box. The role is applied only to the selected object and does not propagate to the child objects.
- Click OK to add the permission.
The permission model for vCenter Server systems relies on assigning permissions to objects in the vSphere object hierarchy. Each permission gives one user or group a set of privileges, that is, a role for the selected object.
You need to understand the following concepts:
Permissions
Each object in the vCenter Server object hierarchy has associated permissions. Each permission specifies for one group or user which privileges that group or user has on the object.
Users and Groups
On vCenter Server systems, you can assign privileges only to authenticated users or groups of authenticated users. Users are authenticated through vCenter Single Sign-On. The users and groups must be defined in the identity source that vCenter Single Sign-On is using to authenticate. Define users and groups using the tools in your identity source, for example, Active Directory.
Roles
Roles allow you to assign permissions on an object based on a typical set of tasks that users perform. Default roles, such as Administrator, are predefined onvCenter Server and cannot be changed. Other roles, such as Resource Pool Administrator, are predefined sample roles. You can create custom roles either from scratch or by cloning and modifying sample roles.
Privileges
Privileges are fine-grained access controls. You can group those privileges into roles, that you can then map to users or groups.
To assign permissions to an object, you follow these steps:
1. Select the object in the vCenter object hierarchy to which you want to apply the permission.
2. Select the group or user that should have privileges on the object.
3. Select the role, that is the set of privileges, that the group or user should have on the object. By default, permissions propagate, that is the group or user has the selected role on the selected object and its child objects.
Hierarchical Inheritance of Permissions
When you assign a permission to an object, you can choose whether the permission propagates down the object hierarchy. You set propagation for each permission. Propagation is not universally applied. Permissions defined for a child object always override the permissions that are propagated from parent objects.
vSphere Inventory Hierarchy
Most inventory objects inherit permissions from a single parent object in the hierarchy. For example, a datastore inherits permissions from either its parent datastore folder or parent data center. Virtual machines inherit permissions from both the parent virtual machine folder and the parent host, cluster, or resource pool simultaneously.
Create/Clone/Edit vCenter Server Roles
Creating a Custom Role
You can create vCenter Server custom roles to suit the access control needs of your environment.
If you create or edit a role on a vCenter Server system that is part of the same vCenter Single Sign-On domain as other vCenter Server systems, the VMware Directory Service (vmdir) propagates the changes that you make to all other vCenter Server systems in the group. Assignments of roles to specific users and objects are not shared across vCenter Server systems.
Prerequisites
Verify that you are logged in as a user with Administrator privileges.
Procedure
1. Log in to vCenter Server with the vSphere Web Client.
2. Select Home, click Administration, and click Roles.
3. Click the Create role action (+) button.
4. Type a name for the new role.
5. Select privileges for the role and click OK.
Once you’ve created or modified the roles as needed, you can assign the roles to the users and groups associated with your ESX/ESXi host or vCenter Server.
Cloning a Role
You can make a copy of an existing role, rename it, and edit it. When you make a copy, the new role is not applied to any users or groups and objects. You must assign the role to users or groups and objects.
If you create or edit a role on a vCenter Server system that is part of the same vCenter Single Sign-On domain as other vCenter Server systems, the VMware Directory Service (vmdir) propagates the changes that you make to all other vCenter Server systems in the group. Assignments of roles to specific users and objects are not shared acrossvCenter Server systems.
Prerequisites
Verify that you are logged in as a user with Administrator privileges.
Procedure
1. Log in to vCenter Server with the vSphere Web Client.
2. Select Home, click Administration, and click Roles.
3 Select a role, and click the Clone role action icon.
4 Type a name for the cloned role.
5 Select or deselect privileges for the role and click OK.
Edit a Role
When you edit a role, you can change the privileges selected for that role. When completed, these privileges are applied to any user or group that is assigned the edited role.
If you create or edit a role on a vCenter Server system that is part of the same vCenter Single Sign-On domain as other vCenter Server systems, the VMware Directory Service (vmdir) propagates the changes that you make to all other vCenter Server systems in the group. Assignments of roles to specific users and objects are not shared across vCenter Server systems.
Prerequisites
Verify that you are logged in as a user with Administrator privileges.
Procedure
1. Log in to vCenter Server with the vSphere Web Client.
2. Select Home, click Administration, and click Roles.
3. Select a role and click the Edit role action button.
4. Select or deselect privileges for the role and click OK.
Configure VMware Directory Service
The VMware Directory service (vmdir) is associated with the domain you specify during installation and is included in each embedded deployment and on each Platform Services Controller. This service is a multi-tenanted, multi-mastered directory service that makes an LDAP directory available on port 389. The service still uses port 11711 for backward compatibility with vSphere 5.5 and earlier systems.
If your environment includes more than one instance of the Platform Services Controller, an update of vmdir content in one vmdir instance is propagated to all other instances of vmdir.
Starting with vSphere 6.0, the VMware Directory Service stores not only vCenter Single Sign-On information but also certificate information.
Replace the VMware Directory Service Certificate (from the Security Guide)
If you decide to use a new VMCA root certificate, and you unpublish the VMCA root certificate that was used when you provisioned your environment, you must replace the machine SSL certificates, solution user certificates, and certificates for some internal services.
If you unpublish the VMCA root certificate, you must replace the SSL Signing Certificate that is used by vCenter Single Sign-On. See “Refresh the Security Token Service (STS) Root Certificate,” on page 36. You must also replace the VMware Directory Service (vmdir) certificate.
Prerequisites
Request a certificate for vmdir for your third-party or enterprise CA.
Procedure
- Stop vmdir.
Linux: service-control –stop vmdird
Windows: service-control –stop VMWareDirectoryService
- Copy the certificate and key that you just generated to the vmdir location.
Linux: cp vmdir.crt /usr/lib/vmware-vmdir/share/config/vmdircert.pem
cp vmdir.priv /usr/lib/vmware-vmdir/share/config/vmdirkey.pem
Windows: copy vmdir.crt C:\programdata\vmware\vCenterServer\cfg\vmdird\vmdircert.pem
copy vmdir.priv C:\programdata\vmware\vCenterServer\cfg\vmdird\vmdirkey.pem
- Restart vmdir from the vSphere Web Client or using the service-control command.
Linux: service-control –start vmdird
Windows: service-control –start VMWareDirectoryService
Apply a role to a User/Group and to an object or group of objects
There a few things to keep in mind when configuring access controls in VMware, however. First of all, if a group is assigned a role, all of the users in that group are given those same privileges unless the users have roles of their own assigned. Second of all, if a user is assigned privileges in VMware, those privileges take precedence over the privileges of the group.
For example, User A and User B are assigned to Group 1. Group 1 has been assigned the Read-Only role. User A doesn’t have a role assigned to it, so it automatically gets all of the permissions given to Group 1. User B, however, has been assigned the No Access role, so User B has no permissions at all.
VMware also validates the users and groups in Windows Active Directory against the users and groups in vCenter Server. So, if a user or group exists in vCenter Server, but doesn’t exist in the domain, VMware will delete all of the permissions associated with the user or group during validation.
You can also assign privileges to multiple inventory objects in VMware by creating a folder and moving all of the appropriate objects to that folder.
Assigning a Role
1. Go to Home, Inventory, and then Hosts and Clusters. Click the inventory object and then click “Permissions.”
2. Right-click an empty area in the right pane, then click “Add Permissions” to open the Assign Permissions window.
3. Click “Add” and insert the appropriate user(s) or group(s). Select the desired role for the user(s) from the drop-down menu.
4. Review the list of permissions in the right pane. To prevent access to child objects, uncheck “Propagate to Child Objects.”
5. Click “OK” to assign the permissions to the selected user(s) or group(s).
Change permission validation settings
vCenter Server periodically validates its user and group lists against the users and groups in the Windows Active Directory domain. It then removes users or groups that no longer exist in the domain. You can change the interval between validations.
Procedure
- From the vSphere Client connected to a vCenter Server system, select Administration > vCenter Server Settings.
- In the navigation pane, select Active Directory.
- (Optional) Deselect the Enable Validation check box to disable validation. Validation is enabled by default. Users and groups are validated when vCenter Server system starts, even if validation is disabled.
- If validation is enabled, enter a value in the Validation Period text box to specify a time, in minutes, between validations.
Many tasks require permissions on more than one object in the inventory. You can review the privileges that are required to perform the tasks and, where applicable, the appropriate sample roles.
If the task that you want to perform is not in this table, the following rules can help you determine where you must assign permissions to allow particular operations:
- Any operation that consumes storage space, such as creating a virtual disk or taking a snapshot, requires the Datastore.Allocate Space privilege on the target datastore, as well as the privilege to perform the operation itself.
- Moving an object in the inventory hierarchy requires appropriate privileges on the object itself, the source parent object (such as a folder or cluster), and the destination parent object.
- Each host and cluster has its own implicit resource pool that contains all the resources of that host or cluster. Deploying a virtual machine directly to a host or cluster requires the Resource.Assign Virtual Machine to Resource Pool privilege.
The images below present common tasks that require more than one privilege. You can add permissions to inventory objects by pairing a user with one of the predefined roles, or you can create custom roles with the set of privileges that you expect to use multiple times.
vCenter Server provides system roles and sample roles by default:
System roles
System roles are permanent. You cannot edit the privileges associated with these roles.
Sample roles
VMware provides sample roles for certain frequently performed combination of tasks. You can clone, modify or remove these roles.
vCenter Server System Roles
A role is a predefined set of privileges. When you add permissions to an object, you pair a user or group with a role. vCenter Server includes several system roles, which you cannot change. vCenter Server provides a small number of default roles. You cannot change the privileges associated with the default roles. The default roles are organized as a hierarchy; each role inherits the privileges of the previous role. For example, the Administrator role inherits the privileges of the Read Only role. Roles that you create do not inherit privileges from any of the system roles.
- Administrator Role
Users assigned the Administrator role for an object are allowed to view and perform all actions on the object. This role also includes all privileges inherent in the Read Only role. If you are acting in the Administrator role on an object, you can assign privileges to individual users and groups. If you are acting in the Administrator role in vCenter Server, you can assign privileges to users and groups in the default vCenter Single Sign-On identity source. Supported identity services include Windows Active Directory and OpenLDAP 2.4.
By default, the administrator@vsphere.local user has the Administrator role on both vCenter Single Sign-On and vCenter Server after installation. That user can then associate other users with the Administrator role on vCenter Server.
- No Access Role
Users assigned the No Access role for an object cannot view or change the object in any way. New users and groups are assigned this role by default. You can change the role on an object-by-object basis.
The administrator@vsphere.local user, the root user, and vpxuser are the only users not assigned the No Access role by default. Instead, they are assigned the Administrator role. You can remove the root user from any permissions or change its role to No Access as long as you first create a replacement permission at the root level with the Administrator role and associate this permission with a different user.
- Read Only Role
Users assigned the Read Only role for an object are allowed to view the state of the object and details about the object. With this role, a user can view virtual machine, host, and resource pool attributes. The user cannot view the remote console for a host. All actions through the menus and toolbars are disallowed.
vCenter Server Sample Roles
- Virtual Machine Administrator: A sample role that allows a user complete and total control of a virtual machine or a host, up to and including removing that VM or host
- Virtual Machine Power User: A sample role that grants a user access rights only to virtual machines; can alter the virtual hardware or create snapshots of the VM
- Virtual Machine User: Grants user access rights exclusively to VMs. The user can power on, power off, and reset the virtual machine, as well as run media from the virtual discs.
- Resource Pool Administrator: Allows the user to create resource pools (RAM and CPU reserved for use) and assign these pools to virtual machines
- Datacenter Administrator: Permits a user to add new datacenter objects
- VMware Consolidated Backup User: Required to allow VMware Consolidated Backup to run
- Datastore Consumer: Allows the user to consume space on a datastore
- Network Consumer: Allows the user to assign a network to a virtual machine or a host
For a list of Common Privileges, scroll down to “Determine the appropriate set of privileges for common tasks in vCenter Server”
Click here for a complete list of Defined Privileges.
Determine the correct roles/privileges needed to integrate vCenter Server with other VMware products
Global permissions are applied to a global root object that spans solutions, for example, both vCenter Server and vCenter Orchestrator. Use global permissions to give a user or group privileges for all objects in all object hierarchies.
Each solution has a root object in its own object hierarchy. The global root object acts as a parent object to each solution object. You can assign global permissions to users or groups, and decide on the role for each user or group.
This week I am at San Francisco for VMworld 2015. This is my first time at VMworld, and I am really enjoying the event. This past Sunday we had a really busy and long day. The day started with a nice breakfast at Mel’s, thanks to Simplivity for picking up the tab. Then I continued my day with some Best Practices, I try to stay away from marketing sessions as much as possible. My first stop was at session #PAR6421, Best Practices for Deploying IaaS with vCloud Suite and vRealize Automation. The session discussion was around Process, Architecture, Backup, and Upgrading. The basic idea is not too different than any other consulting engagement. The first and most important advice is to ask the customer what is it that they want, then design for that aligning your solution and products with those needs. For automation, is important to understand the day to day tasks of the administrator, and try to automate those first. Pay attention to repetitive tasks, automating those will lower the errors due to a manual process. The basic idea here is to understand the processes and make sure that these processes are good, it is a huge mistake to automate a bad process (garbage in, garbage out).
