In the world of vSphere, ensuring that users have the appropriate access and permissions to perform tasks is of utmost importance. To manage this effectively, vSphere offers multiple authorization models that dictate which actions a user is permitted to carry out. This blog post delves into the core concepts of vSphere authorization, focusing on group membership, roles, global permissions, and local vCenter Server permissions.
Understanding Group Membership and Roles in vSphere
vSphere employs a comprehensive system to ascertain if a user has the necessary authorization to perform a specific task. This system is primarily based on group membership within a vCenter Single Sign-On group, which defines the set of actions you are permitted to execute. Furthermore, your assigned role on an object or your global permission level influences your ability to carry out additional tasks.
vCenter Server Permissions
The vCenter Server systems’ authorization framework is built upon assigning permissions to entities within the object hierarchy. Users can obtain permissions in the following ways:
- Through explicit permissions designated for the user or via membership in specific groups
- Through permissions associated with an object or inherited from a parent object in the hierarchy
Each permission assigns a particular role, encompassing a set of privileges, to an individual user or group for a specific object. The vSphere Client can be utilized to assign permissions. For instance, you can right-click on a virtual machine, choose ‘Add Permission,’ and complete the subsequent dialog box to assign a role to a user group. This role grants the users in that group the relevant privileges for the selected virtual machine.
Global Permissions Explain
Global permissions grant users or groups the ability to access or manage all objects across each inventory hierarchy of the solutions present in the deployment. In other words, global permissions pertain to a global root object encompassing multiple solution inventory hierarchies (such as vCenter Server, vRealize Orchestrator, etc.). Additionally, global permissions apply to global objects like tags and content libraries. For instance, imagine a deployment that includes both vCenter Server and vRealize Orchestrator solutions. Global permissions enable you to allocate a role with read-only access to a user group, granting them visibility to all objects within the vCenter Server and vRealize Orchestrator object hierarchies.
Global permissions are replicated throughout the vCenter Single Sign-On domain (by default, vsphere.local). However, these permissions do not authorize services managed via vCenter Single Sign-On domain groups. For more information, refer to the ‘Using vCenter Server Global Permissions’ section.
vCenter Single Sign-On Group Membership
Being a member of a vCenter Single Sign-On domain group permits users to execute specific tasks. For example, membership in the LicenseService. The administrators’ group allows you to manage licenses. For further details, consult the vSphere Authentication documentation.
Comprehending the Object-Level Permission Model
To authorize a user or group to carry out tasks on vCenter Server objects, permissions are applied to the specific object. Technically speaking, when a user attempts to perform an action, an API method is triggered. vCenter Server verifies the permissions related to that method to determine if the user is authorized to execute the operation. For instance, when a user attempts to add a host, the AddStandaloneHost_Task method is initiated. This method necessitates that the user’s role possesses the Host.Inventory.AddStandaloneHost privilege. If the privilege is not found during the check, the user is denied permission to add the host.
It is crucial to understand the following concepts:
Each object in the vCenter Server object hierarchy possesses its own set of permissions. PermissionUsers and Groups define the privileges a specific group or user has on the object for each individual user or group. These permissions can be inherited by child objects.
Users and Groups
In vCenter Server systems, privileges can only be assigned to authenticated users or groups of authenticated users. User authentication occurs through vCenter Single Sign-On. To authenticate users and groups, they must be defined in the identity source utilized by vCenter Single Sign-On. To define users and groups, use the tools provided by your identity source, such as Active Directory.
Privileges represent granular access controls. These privileges can be organized into roles, which can then be mapped to users or groups.
Roles comprise collections of privileges, enabling you to assign permissions to an object based on a standard set of tasks that users typically execute. System roles, like Administrator, come pre-defined on vCenter Server and cannot be altered. Additionally, vCenter Server offers default sample roles, such as Resource Pool Administrator, which can be modified as needed. Custom roles can be created either from the ground up or by cloning and modifying existing sample roles. For more information, refer to the ‘Create a vCenter Server Custom Role’ section.
To allocate permissions to an object, follow these steps:
- Choose the object in the vCenter Server object hierarchy to which you want to apply the permission.
- Select the group or user that should possess privileges for the object.
- Choose individual privileges or a role, representing a collection of privileges, to be held by the group or user for the object.
- By default, ‘Propagate to children’ is not selected. To grant the selected role to the chosen group or user for both the selected object and its child objects, enable the checkbox.
vCenter Server provides sample roles that encompass frequently used privilege combinations. Additionally, custom roles can be created by merging multiple sets of roles.
Often, permissions need to be defined for both a source object and a destination object. For instance, when relocating a virtual machine, privileges are required for the virtual machine itself and the destination data center.
vCenter Server User Validation
vCenter Server systems utilizing a directory service routinely verify users and groups against the user directory domain. This validation takes place at regular intervals, as specified in the vCenter Server settings. For instance, imagine that user Angry is assigned a role on multiple objects. The domain administrator then changes the name to Angry2. When the next validation occurs, the host determines that Angry no longer exists and revokes permissions associated with that user from the vSphere objects.
In a similar manner, if user Angry is removed from the domain, all permissions associated with that user are eliminated during the subsequent validation. If a new user named Angry is added to the domain before the next validation takes place, this new user Angry assumes the permissions of the old user Angry on any object.
Hierarchical Inheritance of Permissions in vSphere
When allocating permission to an object, you have the option to determine if the permission is inherited down the object hierarchy. Propagation settings are configured for each permission individually, rather than being applied universally. Permissions explicitly defined for a child object will always take precedence over permissions inherited from parent objects.
The diagram below demonstrates the inventory hierarchy and the potential paths through which permissions can propagate:
NOTE: Direct permissions cannot be assigned to VM, host, network, and storage folders. These folders serve as containers and, as a result, are not visible to users. Furthermore, it is not possible to set permissions on standard switches.
NOTE: To be able to set and propagate permissions to children on a vSphere Distributed Switch (VDS), the switch object must reside in a network folder created on the data center.
In most cases, inventory objects inherit permissions from a single parent object within the hierarchy. For instance, a datastore acquires permissions from either its parent datastore folder or parent data center. Virtual machines inherit permissions concurrently from both the parent virtual machine folder and the parent host, cluster, or resource pool.
As an example, to set permissions for a distributed switch and its corresponding distributed port groups, you can assign permissions to a parent object like a folder or data center. Additionally, you must choose to propagate these permissions to child objects.
Permissions manifest in various forms throughout the hierarchy
Managed entities pertain to the vSphere objects listed below. Each managed entity offers distinct operations, depending on the entity type. Privileged users have the ability to define permissions on these managed entities. For further details on vSphere objects, properties, and methods, consult the vSphere API documentation.
- Data centers
- Datastore clusters
- Networks (except vSphere Distributed Switches)
- Distributed port groups
- Resource pools
- Virtual machines
- vSphere vApps
You cannot modify permissions on entities that derive permissions from the root vCenter Server system.
- Custom fields
- Statistics intervals
🔥Subscribe to the channel: https://bit.ly/3vY16CT🔥
🚨Read my blog: https://angrysysops.com/
🛒 VMware EMEA store: https://imp.i263671.net/c/3505578/814646/11461
🛒 VMware US store: https://imp.i263671.net/c/3505578/814642/11461
🛒 VMware APAC store: https://imp.i263671.net/c/3505578/814645/11461