6.1 Best Practices for Shared vCenter Server RBAC Design
The following is a list of common and best practices for configuring role-based access control within a shared vCenter Server architecture:
• Any permissions granted to a user account for vCenter Server access must be a privileged account.
• All permissions are assigned to AD groups, not user accounts. Do not use local accounts or groups.
• Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage the permissions structure of each tenant.
• Create new groups for vCenter Server tenant and service provider users. Avoid using Windows built-in groups or other existing groups.
• 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 could unintentionally restrict administrators' privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
• Use data center objects or folders to group objects to correspond to tenants, differing the permissions you want to grant for them.
• Use caution when granting a permission at the root vCenter Server level. Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses. Changes to licenses and roles propagate to all vCenter Server systems in an Enhanced Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
• In most cases, enable propagation on permissions. This provides that when new objects are inserted into the inventory hierarchy, they inherit permissions and are accessible to tenant admins and users.
• Use the No Access role to mask specific areas of the hierarchy that you do not want particular tenant administrators and users to have access to.
• Certain privileges can be harmful to hosts and should be assigned to tenants only when required. This includes any privilege that allows a user to delete, rename, remove, or create items that can cause data loss or datastores to be filled up. This can cause a denial of service attack on your VMs (for instance, prevent snapshot creation).
• Create roles that are customized to tenant requirements. For example, to create a role for an operations team that is responsible for monitoring VMs, create one that allows VM interactions only (for instance, power on, power off, reset, and console interaction). This allows team members to look at the console of a VM to see what is happening and power-cycle a VM.
• Assign the datastore low-level file operations privilege sparingly. This privilege allows users to upload and download files to a host datastore and can create a security risk.
Other potentially dangerous privileges are in the network and distributed virtual switch categories, which can allow a user to move a VM to any available virtual LAN that is configured on your virtual switches. This can be particularly risky if you have public and private network virtual switches on a host where you definitely do not want a VM moved between them or connected to both at the same time. Assigning the network privileges to your tenant administrators and denying them to everyone else is a good practice.