Best Practices for vCenter Server Roles and Permissions

Follow best practices for roles and permissions to maximize the security and manageability of your vCenter Server environment.

Follow these best practices when configuring roles and permissions in your vCenter Server environment:

• Where possible, assign a role to a group rather than individual users.
• Grant permissions only on the objects where they are needed, and assign privileges only to users or groups that must have them. Use the minimum number of permissions to make it easier to understand and manage the structure of your permissions.
• If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges. Otherwise, you might unintentionally restrict privileges of administrators in the parts of the inventory hierarchy where you have assigned that group the restrictive role.
• Group objects into folders to make assigning permissions easier. For example, to grant the modify permission on one set of hosts and the view permission on another set of hosts, place each set of hosts in a folder.
• Use caution when adding a permission to the root vCenter Server objects. Users with privileges at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings.
• Consider enabling propagation when you assign permissions to an object. Propagation ensures that new objects in the object hierarchy inherit permissions. For example, you can assign a permission to a virtual machine folder and enable propagation to ensure that the permission applies to all virtual machines in the folder.
• Use the No Access role to mask specific areas of the hierarchy. The No Access role restricts access for the users or groups with that role. However, in the case of VMs and vAPPs, there are two permission propagation chains. Assigning a propagating permission with No Access role on one of the chains, does not imply that the respective vApp or VM would have no privileges propagated to it.
• Changes to licenses propagate to all linked vCenter Server systems in the same vCenter Single Sign-On domain.
• License propagation happens even if the user does not have privileges on all vCenter Server systems.