Some notes on VMware vSphere Security Permissions

To provide access to various categories of users to their virtual machines, as a rule, they use the VM and Templates view and a system of folders 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 environment objects that are not in the VM and Templates display. For example, to add a virtual hard disk or to clone VMs, you need Datastore.Allocate Space permissions or the Datastore Consumer role on a Datastore or Datastore Cluster object. And for the ability to change the network interface - the right Network.Assign Network or the role of the Network Administrator on the relevant portgroups. Further details on this and other nuances of assigning access rights in the vSphere. Information relevant to versions vSphere 5.1 and 5.5.

Due to the presence of different representations of virtualization infrastructure objects, 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 shown in the figure:


')
Accordingly, if you need to restrict someone, you need to make sure that the rights taken away in one place are not inherited from another object.

In addition, it can be encountered in practice that a person who has administrator authority at the root level suddenly finds himself limited by user rights at the level of a specific folder. The point is in the peculiarities of the choice of existing rights in the situation of imposing roles. When granting credentials you should keep them in mind.

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

2) Rights granted to a specific user prevail over rights granted to a group (if both are granted to one object and the user is included in the group).

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

4) vCenter SSO does not inherit the rights of nested groups if their members are not included in Identity Sources . For example, if an AD domain is not added to Identity Sources, then the Domain Admins group of this domain will have no authority on the vCenter, even if it belongs to the local \ Administrators of the vCenter server.

A few recommendations of the best dog breeders of Best Practices on the topic of granting access rights.

• Whenever possible, assign rights to groups, and not to specific users. Control of group membership can be delegated and rid yourself of unnecessary work. And even if not delegated, the system will be easier to manage.
• To issue rights only where necessary, to those who need it and with the minimum necessary privileges. Again for understanding the structure, simplifying management and proper control. It is better to form in advance a plan of the necessary powers and the 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 only in VM and Templates.
• Be careful about granting rights at the root level. That is, at the level of the vCenter itself in the vSphere client. The fact is that a user who has rights at this level gains access not only to objects of the virtualization infrastructure, but also to the management of such entities as licenses, roles, statistics collection intervals, sessions and customized fields. And the possibility of modifying roles can have an effect even on those vCenter, on which the user does not have rights at all (when using Linked Mode).
• In most cases, it is worth including inheritance. This ensures that when a new object is added to a certain hierarchy, the user responsible for it will gain access to it.
• To disguise specific areas of the hierarchy, you can use the role of "No Access"
• After rebooting and updating vCenter, you should check for the necessary rights. The fact is that if at some stage there are 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. Give rights to a specialized group.

Finally, I will mention the specialized users of ESXi hosts. It was provoked by the fact that a colleague once decided to make sure that IT staff in some regions didn’t create any loopholes in the infrastructure, and almost got rid of 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, respectively, administrative rights to the host and in no case should not be upgraded (do not change neither the right nor the password).

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

As a conclusion, I want to note that I have never been so aware of the importance and relevance of the AGDLP approach in 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 branching elements of hierarchies.