Ever wondered how you can give a user access to some artifacts within a vCenter and then deny the same user access to other artifacts?
The access hierarchy in vCenter is role-based, leveraging permissions applied at various object levels in the vSphere inventory. Here’s a breakdown
Permissions = User/Group + Role + Object
Access is granted when a user or group is assigned a role (set of privileges) on a specific inventory object (like a VM, cluster, or datastore).
Hierarchical Structure of vCenter Inventory
vCenter’s inventory is hierarchical and permission inheritance flows top-down unless explicitly disabled. Here’s the structure from top to bottom:
vCenter Root
│
├── Datacenter(s)
│ ├── Cluster(s)
│ │ ├── Host(s)
│ │ │ ├── VM(s)
│ │ │ └── Resource Pools
│ │ └── DRS/HA settings
│ ├── Storage (Datastores, Datastore Clusters)
│ └── Networking (Port Groups, dvSwitches)
Inheritance Behavior
- Permissions propagate downward unless you check “Propagate: No” when assigning the permission.
- Permissions do not propagate upward — no automatic access to parent objects.
- Conflicts are resolved by the most specific object’s permission.
Types of Roles (Built-in & Custom)
Roles define sets of privileges. vCenter comes with several built-in roles:
- Administrator – Full control.
- Read-Only – View-only access.
- No Access – Deny access (used to explicitly block).
- Virtual Machine Power User – VM-specific operations.
- Resource Pool Administrator, etc.
You can create custom roles for fine-grained control (e.g., “Helpdesk VM Operator” or “Backup Admin”).
Common Object-Level Access Design
| Object Level | Common Use Case |
|---|---|
| vCenter Root | Global Admins – infrastructure-wide control |
| Datacenter | Region- or function-specific control |
| Cluster | Workload team separation (e.g., Dev, Prod) |
| Host | Seldom directly assigned, usually via cluster |
| VM | Helpdesk or app team access |
| Datastore | Backup/Storage teams |
| Resource Pool | Chargeback / resource segregation |
| vDS / Portgroup | Network team access |
Identity Integration
vCenter supports:
- vSphere SSO Domain (vsphere.local)
- Active Directory / LDAPS
- Enhanced Linked Mode (ELM) – Federates multiple vCenters with common SSO
You assign Active Directory groups to roles for scalable RBAC, especially in large enterprises.
Security Best Practices
- Use Groups over Individual Users – Easier to audit and manage.
- Principle of Least Privilege – Assign only needed permissions.
- Avoid Using Administrator Role – Especially for service accounts.
- Audit Permissions Regularly – Especially after organizational changes.
- Isolate Tenants with Folder/Resource Pools – For multi-tenancy or departmental control.
Advanced Architect Tips
- Tag-Based Access Control (TBAC): From vSphere 7+, you can use tags + automation tools (e.g., vRealize Orchestrator) to apply policies dynamically.
- vRealize Automation (vRA) integration can abstract underlying hierarchy from users.
- Service Accounts: Use custom roles with limited privileges, and audit often.
