Cloud permissions for VMware vSphere (Roles, Privileges and Permissions)
VMware vSphere offers powerful native tools to manage users’ access to resources in a vSphere environment. Administrators may create custom Roles that are composed of one or more granular Privileges. Each Privilege is the most granular right that can be ascribed within vSphere, such as the ability to power-on a virtual machine (NOTE: power-off is a separate privilege!).
Once created, a Role and a user/group (users/groups may be chosen from any authorized Identity Source such as: SSO, AD, LDAP) are combined to create a Permission. The Permission is then applied to a specific Inventory item in vCenter, with the net result that the user/group is able to invoke only the specific Privileges on the Inventory items to which they have been assigned!
It works like this:
If you created a vCenter Role called “VM Power” and added only the Privileges to power-on and power-off VMs, then:
- If you assigned the Permission (User/Role combination) to a specific VM, then the user could only power-on or power-off that specific VM! Not only that, the user could only even see the VM to which the permission had been assigned.
- If you assigned the Permission (User/Role combination) to an ESXi Host, then the user could see and power-on or power-off all VMs on that ESXi Host, but no other VMs in the environment.
Permissions may be assigned to all inventory items in vCenter including: Folders, Resource Pools, Networks (Port Groups), and Datastores. By choosing to propagate or not propagate a specific Permission, administrators may enact very precise control over users, what items they can see and what they can do with those items.
VMware would have you believe that to create or manage a “Cloud” with vSphere, separate “Cloud” products are required at additional expense. Nothing could be further from the truth! By applying a vSphere Permission to a Resource Pool, a Private Cloud is effectively created conforming to the Essential Characteristics as provided by the NIST Definition of Cloud Computing :
- On-demand self-service: Users may invoke Privileges they have been authorized on resources they have been assigned.
- Broad network access: Users may choose any common platform to access their resources.
- Resource Pooling: Users have access to specific, named resources and no visibility to other resources abstracted by the same hypervisor and/or vSphere Cluster
- Rapid Elasticity: The resources may be instantaneously grown to the limits available in the vSphere Cluster
- Measured Service: Compute resources may be assigned and measured on a per Megabyte/Gigabyte and per Megahertz/Gigahertz basis.
The goals in creating a vSphere Permission for Private Cloud Computing, or just user/applications are:
- Limit user/group access to only assigned resources.
- User should not be able to see or interact with resources which have not been specifically assigned.
- User should not be able to observe Compute resources except those specific resources to which they have been assigned
- User should not be able to access networks and datastores except those to which they have been assigned
- Allow user/group should full-control over specific resources in their Cloud
- User should be able to Create / Deploy / Clone and Delete Virtual Machines
- User should have Remote Console access to Virtual Machines
- User should be able to browse assigned Datastores
- User should be able to assign networks
The trick to creating vSphere permissions that will work effectively is setting propagation of the Permission! For example:
Given that in order to create a new Virtual Machine, a user must have the Privilege “Create New” assigned at the Datacenter level.
If a Permission is created allowing that Privilege at the Datacenter level, but allowed to propagate, than any affected users will be able to see and interact with any subset of the datacenter; we have not met the requirements of Cloud Computing or our goals!
If, however, a Permission is created allowing that Privilege at the Datacenter level, but NOT allowed to propagate, than any affected users will only be able to see and interact with their assigned resources; mission accomplished!
In the steps below, we will create a single vCenter Role that will be applied as a non-propagating Permission at the Datacenter level, and as a propagating Permission for the Resource Pool, Network and Datastore
Here are the steps:
- Go to: Home > Roles
- Choose: Add Role
- Under Datastore, select the following minimum privileges:
- Under Datastore Cluster select the following minimum privileges:
- Under Global select the following minimum privileges:
- Under Resource select the following minimum privileges:
- Under Virtual Machine Virtual Machine, select all Privileges, or the minimum Privilege level as defined in the table: vCenter Privileges required for Cloud Computing
- Go to: Home > Hosts & Clusters
- Select the Datacenter
- Right-click and choose: add permission
- Under Users and Groups, click: Add
- Choose your user/group
- Under Assigned Role
- Chose the Role you created earlier
- Un-check Propagate to Child Objects
- Go to: Home > Hosts & Clusters
- Select the Resource Pool
- Right-click and choose: add permission
- Under Users and Groups, click: Add
- Choose your user/group
- Under Assigned Role
- Chose the Role you created earlier
- Leave checked Propagate to Child Objects
- Go to: Home > Datastores and Datastore Clusters
- Select the objects to be assigned (datastores / Datastore Clusters)
- GO to the Permissions Tab then right-click and choose: add permission
- Under Users and Groups, click: Add
- Choose your user/group
- Under Assigned Role
- Chose the Role you created earlier
- Go to: Home > Networking
- Select the Network(s)
- Right-click and choose: add permission
- Under Users and Groups, click: Add
- Choose your user/group
- Under Assigned Role
- Chose the Role you created earlier
- Log-in as a test-user and validate your work!
Minimum vCenter Privileges required for Cloud Computing:
- Datastore
- Allocate space
- Browse datastore
- Low-level file operations
- Remove file
- Update Virtual Machine Files
- Datastore Cluster
- Configure a datastore cluster
- Global
- Disable methods
- Enable methods
- Licenses
- Log event
- Manage custom attributes
- Set custom attribute
- Resource
- Assign virtual machine to resource pool
- Apply Recommendation
- Create Resource Pool
- Remove Resource Pool
- Rename Resource Pool
- Virtual Machine
- Add existing disk
- Add new disk
- Advanced
- Change resource
- Disk change tracking
- Disk lease
- Remove disk
- Device connection
- Guest operating system
- management by VIX API
- Register
- Remove
- Allow disk access
- Allow read-only disk access
- Allow virtual machine
- download
- Create snapshot
- Remove snapshot
- Revert to snapshot
- Add virtual machine
- Assign resource pool
- Unregister
Hello John
I feel a bit uncomfortable giving those permissions/rights that far up the tree. Wouldn’t it work to just give the user read-only+no propagate for each major object (datacenter, cluster, parent resource pool), and then apply the more powerful role/priv to the specific resource pool/folder?
Cheers!
Mark
You give the user only the rights they require to do the job at hand. The example I gave is for Veeam Backup and Replication. Also, if you place a permission + no propagate on each major object, then you have to manage many permissions. Simplicity=elegance!