Restrict Users and Groups to Resource Pools

With the speed and simplicity of virtualization, it’s no wonder more and more people want in! Administrators have traditionally been responsible for deploying virtual workloads for an organization. However, in some cases, they may want to remove themselves from the provisioning process and give that power to the users themselves.

Say for example you work for a small software company where budgets are tight and resources are limited. Your developers need many virtual machines spun up throughout the day and can’t usually wait for an administrator to handle their requests. You could build them their own vCenter with a bunch of hosts, but what if you don’t have the money or hardware to spare?

One answer could be resource pools. A resource pool is simply a logical unit of compute and memory resources. They can be used to guarantee and/or limit resources for a group of virtual machines.

How exactly do you restrict users and groups to resource pools?

Since a resource pool is a vCenter object, it is possible to delegate users and groups to a pool. This means that they would only have the ability to create virtual machines within their assigned pool. Think of it as a private cloud within a private cloud. Yo dawg!

This seems pretty straightforward so far, but here’s where things get a little more complicated. Permissions! Admittedly, I struggle a bit with vCenter Permissions. Trying to configure them just right is often like trying to solve a puzzle and it may take some trial and error before you finally solve it. Our example of resource pools makes for a pretty complicated entertaining puzzle.

At first, it might appear that granting a group administrative rights to a resource pool would take care of everything.

However, upon further testing you discover that it’s just not that easy.

This diagram shows the minimum permissions needed in order to create a new VM or deploy one from a template.

Note: These are the minimum permissions needed to deploy a VM. You will need to add further permissions to be able to perform other tasks such a removing a VM or taking snapshots.

As you can see, we need to set permissions on four objects within our vCenter, except that permissions cannot be directly applied to an object but roles can. Bear in mind that a role is just a collection of permissions. This may seem a bit convoluted, but it really helps keep things manageable by being able to take a look at a role like “administrator” and see who is assigned those permissions for an object. This is especially helpful when many roles are used. For example, have you ever seen a Windows share with hundreds of users or groups assigned different permissions? If so, then you’ll know how challenging it can be to identify who has full access vs. who has read only.

Today, we’re just going to configure the minimum permissions needed to create and deploy virtual machines to a resource pool. These permissions likely won’t be comprehensive for your users, so you may need to modify them to fit their needs. For a full list of permissions that are available in vCenter, take a look at the vSphere Security Guide and flip to section 10 – Defined Privileges.

Since we’re applying different permissions to four different vCenter objects, that means we’ll need four Roles. I’m going to name my roles based on the department name, Dev, and the vCenter object to which it’s assigned. Name your roles in a way that is most appropriate for you.

Dev – Datacenter

This role needs permission to create new virtual machines and create from existing (for templates or clones). These permissions should propagate to child objects. You could either apply this to all child objects or specific clusters or hosts as well as the resource pool.

Virtual Machine –> Inventory –> Create from existing

Virtual Machine –> Inventory –> Create new

Dev – Network

This role will need permission to attach a switch or port group(s) to a virtual machine. Applying this permission to a switch will allow users to assign any of the switch’s port groups. If you’d like to restrict a group to specific vLAN’s then assign this role to the appropriate port groups. It’s also worth noting that permissions cannot be set for virtual distributed switches, but can be set for their port groups. This permission should propagate to child objects if setting at the switch level or higher.

Network –> Assign network

Dev – Datastore

A resource pool is a great way to limit CPU and memory but has no control over storage. We limit storage by granting permissions to specific datastores. This permission could also be applied to datastore clusters or data centers. This permission should propagate to child objects if applied to datastore clusters or higher level objects.

Datastore –> Allocate space

Dev – Pool

Lastly, we need to be able to deploy and configure our virtual machines within a specific resource pool. These permissions should propagate to child objects.

Resource –> Assign virtual machine to resource pool

Virtual Machine –> Configuration –> Add existing disk

Virtual Machine –> Configuration –> Add new disk

Virtual Machine –> Configuration –> Add or remove device

Assign each of these roles to their respected objects and assign your user groups to these roles. Upon successful completion of this task, your users will only be able to consume resources from their designated resource pools. At first, it may seem like something’s wrong because when a user logs in, they can see more than their resource pool.

That’s because there’s no easy way to hide these objects. But don’t worry, they don’t have permissions to do anything with objects outside their resource pool.

The problem is that this can make things a bit clunky for your users because they can see more objects than they can use. For example, when you create a new VM, the console might show you all available datastores. However, due to how our permissions are configured, you can only create a VM within the assigned datastore(s).

The same goes for the network.

It’s not 100% perfect, but vCenter does a good job of telling a user when they’re trying to consume a resource they don’t have permission to use. It just means you’ll have to do your part in educating your users or let them use a bit of trial and error to sort it out. Either way, once they’ve successfully navigated the VM deployment process, they’ll be up and running with their brand new virtual machine!