Some notes on VMware vSphere Security Permissions

To provide access to various categories of users to their virtual machines, as a rule, the VM and Templates view and the folder system are used, to which, in fact, rights are assigned. However, in some cases this is not enough, because for some actions the user must have rights to environmental objects that are not in the VM and Templates display. For example, to add a virtual hard disk or clone a VM, you need Datastore.Allocate Space permissions or the Datastore Consumer role on a Datastore or Datastore Cluster object. And for the possibility of changing the network interface - Network.Assign Network rights or the Network Administrator role on the corresponding portgroups. Further in more detail about this and other nuances of assigning access rights in vSphere. The information is relevant for vSphere 5.1 and 5.5.

Due to the presence of different representations of objects of the virtualization infrastructure, access rights to some objects (VM, vApps) can be inherited from several ancestors (for example, VM folder and Resource Pool). what to keep in mind. The general scheme of inheritance is presented in the figure:



Accordingly, if someone needs to be restricted in their rights, you need to make sure that the rights taken in one place are not inherited from another object.

In addition, one may encounter in practice that a person who has administrator privileges at the root level suddenly finds himself limited by user rights at the level of a specific folder. The point is in the features of the choice of existing rights in a situation of imposing roles. When granting authority, it should be borne in mind.

1)Rights granted to child objects are ignored by inherited. In other words, if the user is a member of the vSphereAdmins and CitrixAdmins groups, while the first has admin rights at the root level and the second has VM User at the Citrix folder level, then we will just get the situation described in the above paragraph.

2) The rights granted to a particular user prevail over the rights granted to the group (if both of them are issued to the same object and the user is a member of the group).

3) If users from AD or other sources other than the built-in vCenter SSO directory are used, vCenter periodically checks for an account by searching by name. And if, after assigning rights to vCenter, the account was renamed or deleted, the corresponding rights from vCenter are deleted. And if in the case of remote accounting this is even good, then in case someone renames a group (s), for example, in accordance with the new naming policies in the organization, this can lead to adverse consequences.

4) vCenter SSO does not inherit the rights of nested groups if their members are not members of Identity Sources . For example, if the AD domain is not added to Identity Sources, then the Domain Admins group of this domain will not have any vCenter permissions, even though it is a member of the local \ Administrators vCenter server.

Some recommendations from the best breeders Best Practices on the topic of granting access rights.

• If possible, assign rights to groups, not specific users. Control of group membership can be delegated and save yourself from unnecessary work. And even if you do not delegate, the system will be easier to manage.
• Grant rights only where necessary, to those who need and with the minimum necessary privileges. Again, to understand the structure, simplify management and proper control. It is better to formulate in advance a plan of the necessary powers and persons who need them.
• Use folders to group objects with similar sets of rights. Folders, if anything, can be created in all views, and not just in VM and Templates.
• Be careful with granting rights at the root level. That is, at the level of vCenter itself in the vSphere client. The fact is that a user who has rights at this level gets access not only to virtualization infrastructure objects, but also to the management of such entities as licenses, roles, statistics collection intervals, sessions, and customized fields. And the ability to modify roles can even affect vCenter for which the user has no rights at all (when using Linked Mode).
• In most cases, you should include inheritance. This ensures that when a new object is added to a certain hierarchy, the user responsible for it will have access to it.
• To mask specific zones of the hierarchy, you can use the "No Access" role
• After rebooting and updating, vCenter should check for the necessary rights. The fact is that if at some stage there were network problems and vCenter cannot verify the specified groups or users, they will be deleted and replaced by local \ Administrators.
• Remove vCenter rights for the local Administrators group and the vCenter server Administrator user. Grant rights to a specialized group.

Finally, I’ll mention specialized users of ESXi hosts. It was provoked by the fact that a colleague once decided to make sure that IT employees in some regions did not make themselves loopholes in the infrastructure, and almost cleaned up ESXi hosts from the vpxuser user.

vpxuser is a specialized user that is created when a host connects to vCenter and is used by it for administration. It has, accordingly, administrative rights to the host and in no case should it be modernized (do not change either the rights or the password).

dcui user is another specific user that is used as an agent when working through the Direct Console User Interface in the lockdown mode of the host (in this mode, any connections to the host are prohibited, except for management using vCenter).

In conclusion, I want to note that I have never been so aware of the significance and relevance of the AGDLP approach when assigning access rights to the system, as when developing a policy for assigning rights to vCenter objects. In view of the above features and a large number of branches of hierarchy elements.