Roles, Permissions - DataCenter, Folder, Cluster, Host Layout - Best Practices\How-To

[KRichardson5280]

Having a small problem with permissions and roles. I'm sure this will be an easy one for those of you with more experience working with roles. Hopefully my organization layout diagram made with quote boxes is readable.

The organization just spun up a new ESXi 4 host for the developers and added it into vCenter. The developers want to use the vSphere Client\VIC to manage this ESX server. They need to rights to create VMs, delete VMs, clone VMs, power on\off VMs. However, we do not want them to be able to touch production.

Per the diagram below, the new development host, labled as "HostC (Stand-Alone DEVELOPMENT Host)", sits under "DataCenter City-2" which also holds production ESX clusters. And I obviously dont want developers having rights on the production clusters.

Lets say I create a role called "HostC Dev Sandbox Rights", add users and assign it directly to "HostC" listed below. That role contains the "Create VM" right, however when I run the create VM wizard from HostC as a member of the role the vSphere Client tells me this task requires Create VM rights on the DataCenter Level!!!!!! But assigning those developers create VM access on the datacenter would give them rights to create VMs within the Production Clusters!!!!! Which is obviously a problem.

I can't believe that our need to give these rights to ONLY one host in a DataCenter is uncommon. I am sure this is a misunderstanding on my part of how to configure VMware Roles for best practices.

Anyone with more expirence on VMware roles willing to help me out on this one? Thanks in advance!

Organization Layout Diagram using quote boxes:

vSphere (vCenter Server)

DataCenter City-1

Many folders, clusters, hosts

DataCenter City-2

FolderA (Business Unit A)

ClusterA (Production Cluster A)

HostA1 (Production Host in Cluster A)

HostA2 (Production Host in Cluster A)

FolderB (Business Unit B)

ClusterB (Production Cluster B)

HostB1 (Production Host in Cluster B)

HostB2 (Production Host in Cluster B)

HostC (Stand-Alone DEVELOPMENT Host) - Under FolderB but not in the cluster

DataCenter City-3

Many folders, clusters, hosts

[mark_chuman]

Another option would be to just use folders.

Take a look here - vsp_40_u1_admin_guide.pdf on page 219 and 225.

You have to now view the datastore view and the network view as another location to set permissions. For example you could make someone VM admin at the host level, but you will need to assign specific permissions at the datacenter (datastore/network) level like assign virtual machine to resource pool or allocate space in the top level datastore. You only want to grant the specific access needed at the upper most level. Those singular, upper access rights shouldn't mean anything without the cooresponding lower level access rights.

[KRichardson5280]

Thank you, that is very helpful information. (Points Awarded)

Now within the datastore view it appers I can only assign permissions to the datacenter which contains the datastore. Can I not assign permissions directly to an individual datastore?

If my datacenter "City2" contains 2 Production Clusters and a Stand-Alone Development host, and I want to give the user permissions to write to the Stand-Alone Host's local datastore, then it appears I have to set permissions at the datacenter level within the datastore view which includes rights to access production SAN luns on the 2 production clusters? Is that correct?

Now I realize that in the "host an clusters" view they can only see the Development Host "HostC". And it only has the development datastores assigned to it. Thus, they would still only see and access the development datastores via the VSphere client when working in "Host and Clusters" view. Correct?

Two concerns:

1) If they flip to the Datastore view in the vSphere Client\VIC then they would still have direct access to the production LUNs of the 2 production clusters? Correct?

2) After applying permissions in the datastore view on the datacenter, I see more hosts in the host and cluster view. It appears some permissions carry across.

I also see that when I apply permissions in the datastore view those changes get reflected in the Host and Clusters View.

[mark_chuman · Accepted solution]

You can apply permissions directly to the datastore. I don't have a need to go deeper than clusters in our environment, but what would really work well for you is to place datastores into folders in storage view. Have the folders be the names of your clusters in hosts and clusters view. Then place the datastores for each cluster into the corresponding folder. Then you only have to apply permissions for datastores on the folder instead of going into each individual datastore. Off topic a bit, but one thing folders in datastore view lack is the "storage views" functionality, which I put in for a future request.

Yes, if you assign permissision in the datastore view the user can flip the view and see them. Thorough testing of your permissions framework is warranted before pushing out to users. It sounds like you are already doing this.

[KRichardson5280]

I use folders in the "Hosts and Clusters" view all the time. For some reason I never thought to look if they could be used in the datastore view.

Thanks! I think that tweak will work.

[mark_chuman]

Glad that helps. We have quite a few datastores per cluster, so it really becomes a lot to look at when you go into the data stores view. It would be neat if they gave you the option to enable the same cluster icons that are used in host and clusters and for them to automatically group the data stores as they are grouped in the hosts and clusters view.

[mark_chuman]

Found this in the vSphere Upgrade Guide 4.1. Starts on page 49 - Chapter 7 - Upgrading Datastore and Network

Permissions.

In previous releases of vCenter Server, datastores and networks inherited access permissions from the

datacenter. In vCenter Server 4.0 and higher, they have their own set of privileges that control access to them.

This might require you to manually assign privileges, depending on the access level you require.

In vCenter Server 4.x, users are initially granted the No Access role on all new managed objects, including

datastores and networks. This means, by default, users cannot view or perform operations on them. All existing

objects in vCenter Server maintain their permissions after the upgrade. To determine whether to assign

permissions to existing datastores and networks, the upgrade process uses the datacenter's Read-only

privilege.

n If the Read-only privilege is nonpropagating (not inherited by child objects), VMware assumes access

privileges should not be assigned to datastores and networks. In such cases, you must update your roles

to include the new datastore and network privileges desired. This is required for users to view and perform

operations on these objects.

n If the Read-only privilege is propagating (inherited by child objects), VMware assumes access privileges

should be assigned to datastores and networks so users can view them and perform basic operations that

require access. In such cases, the default minimum privileges are automatically assigned during the

upgrade process.

After the upgrade process, if your roles require users to have additional privileges, for example, the ability

to delete a datastore or network, you need to update your permission roles.

Table 7-1 lists the privileges assigned to datastores and networks before the upgrade to vCenter 4.1 and after

the upgrade to vCenter 4.1, and the action required by administrators to enable access.

Table 7-1. Datastore and Network Permission Requirements

Object Before Upgrade Privilege After Upgrade Privilege Action Required to Enable Access

Datastore Nonpropagating Read-only No Access Assign access privileges for datastores or

datastore folders.

Propagating Read-only Allocate Space None.

Network Nonpropagating Read-only No Access Assign access privileges for networks or

network folders.

Propagating Read-only Assign Network None.

NOTE The Read-only propagating permission on a datacenter, as well as all other permissions you have set,

will continue to work as expected after the upgrade.