11.4 Role-Based Access Control
Role-based access control (RBAC) can be employed in a number of different scenarios for VMware Cloud Providers. Internally, from an operational perspective, to verify that only the appropriate operational or administrative teams have access to internal and tenant environments. Also, from the perspective of giving tenants access to either shared or dedicated vCenter Server instances or to hosts directly, allowing for self-managed hosting use cases. No matter what use cases are defined by the service provider, if proper role-based access controls are not in place within the environment, virtual machines will be vulnerable.
The following is a list of common and best practices for designing RBAC for the VMware Cloud Provider Program service provider platform:
• Any vSphere administrative permission granted to a user account must use a privileged account (PA).
• All permissions must be assigned to AD groups and not individual user accounts. Do not use local accounts or groups for day-to-day administration.
• Grant permissions only where needed for job role, using the minimum number of permissions makes it easier to understand and manage the permissions structure.
• Create new groups for vCenter Server users. Avoid using Windows built-in groups or other pre-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 folders to group objects to correspond to the differing permissions you want to grant for them.
• Use caution when granting 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 a 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 makes sure that when new objects are inserted in to the inventory hierarchy, they inherit permissions and are accessible to users.
• Use the No Access role to mask specific areas from the hierarchy that you do not want particular users to have access to.
• Certain privileges can be harmful to hosts and should be assigned to users 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 a user's/tenant’s requirements. For example, to create a role for an operations team that is responsible for monitoring VMs, create one that allows only VM interactions (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.
• A privilege that you assign sparingly is the datastore low-level file operations privilege, which allows users to upload and download files to a host datastore. This privilege can create a
security risk.
• Other potentially dangerous privileges are in the network and 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 (for instance, edge cluster hosts). Assigning the network privileges to your network admins and denying them to everyone else is a good practice.