RBAC (Role-Based Access Control)

Enterprise Feature

Advanced RBAC is available exclusively in the Enterprise edition of ProxCenter. Community users have access to the default system roles (Admin, Operator, Viewer) but cannot create custom roles or configure granular permission scopes.

ProxCenter's RBAC system gives you fine-grained control over who can do what across your infrastructure. Define custom roles with precise permissions and assign them to users to enforce the principle of least privilege.

In multi-tenant deployments, RBAC is evaluated inside the user's tenant assignments. A role grants actions only within the tenant and vDC scopes visible to that user unless the user has provider-level administration rights.

The role editor groups permissions by category and makes tenant-aware, resource-scoped access easier to audit.

System Roles vs Custom Roles

System Roles

ProxCenter ships with three built-in system roles that cannot be modified or deleted:

Role	Description
Admin	Full, unrestricted access to every feature and setting
Operator	Manage infrastructure and perform day-to-day operations
Viewer	Read-only access to dashboards, inventory, and logs

System roles are available in both Community and Enterprise editions.

Custom Roles

With the Enterprise edition, you can create custom roles tailored to your organization's needs. Custom roles allow you to combine any set of permissions into a named role that can be assigned to one or more users.

To create a custom role:

1. Navigate to Security & Access > RBAC / Roles
2. Click Create Role
3. Enter a role name and optional description
4. Select a color for the role badge displayed in the UI
5. Toggle the permissions you want to include
6. Click Save

tip

Use descriptive names like "Backup Operator" or "Network Admin" so that the role's purpose is immediately clear.

Permission Categories

Permissions are organized into the following categories:

VM (vm.*)

Control access to virtual machines and containers.

Permission	Description
vm.view	View VMs and containers, their status and details
vm.start	Start or resume VMs and containers
vm.stop	Stop, shutdown, or suspend VMs and containers
vm.create	Create new VMs and containers
vm.delete	Delete VMs and containers
vm.migrate	Migrate VMs between nodes
vm.snapshot	Create, restore, and delete snapshots
vm.console	Access the VM console

Storage (storage.*)

Control access to storage pools and volumes.

Permission	Description
storage.view	View storage pools and usage
storage.manage	Create, modify, and delete storage configurations

Node (node.*)

Control access to Proxmox hypervisor nodes.

Permission	Description
node.view	View node information and resource usage
node.manage	Manage node settings and configurations

Connection (connection.*)

Control access to Proxmox connection management.

Permission	Description
connection.view	View configured Proxmox connections
connection.manage	Add, edit, and remove Proxmox connections

Backup (backup.*)

Control access to backup operations.

Permission	Description
backup.view	View backup jobs and restore points
backup.create	Create new backup jobs
backup.restore	Restore VMs and containers from backups
backup.delete	Delete backup files and jobs

Operations (events.*, alerts.*, tasks.*, reports.*)

Control access to the day-to-day operations pages.

Permission	Description
events.view	View the aggregated event log
alerts.view	View alert rules and active alerts
alerts.manage	Create, edit, delete, silence and acknowledge alerts
tasks.view	View the Task Center
reports.view	View and generate reports

Creating an alert requires alerts.manage

Until v1.4.8 the creation route was the one write on the resource that carried no permission check, while editing, deleting, silencing and syncing all required alerts.manage. It now requires it too, and the check runs before the request body is read, so a caller without the permission is refused without the payload ever being parsed. Anyone who could already edit an alert rule keeps being able to create one.

Admin (admin.*)

Control access to platform administration.

Permission	Description
admin.users	Manage users and invitations
admin.rbac	Manage roles and permissions
admin.audit	View audit logs
admin.settings	Manage platform settings and license
admin.tenants	Manage tenants, connection ownership, and tenant users

Permission Scopes

Permissions can be applied at different scopes to control the breadth of access:

Scope	Description
Global	Permission applies across all connections, nodes, and VMs
Connection	Permission is limited to resources under a specific Proxmox connection
Node	Permission is limited to resources on a specific Proxmox node
VM	Permission is limited to a specific virtual machine or container
Tag	Permission is limited to the guests carrying a specific Proxmox tag
Pool	Permission is limited to the guests of a specific Proxmox resource pool

Scopes allow you to create roles like "Operator for Production Cluster" or "Viewer for node-03 only," giving you precise control over access boundaries.

The tenant is not one of these scopes

Every grant already carries the tenant it was made in, so tenancy is a boundary applied on top of the scope rather than a scope value you pick. For MSP and IaaS deployments the tenant is usually the primary boundary: MSP tenants own whole connections, while IaaS tenants are limited to their vDCs. The scopes above then refine access inside that boundary, and the same user can hold different grants in different tenants.

info

When a permission is granted at a broader scope, it automatically applies to all narrower scopes beneath it. For example, granting vm.view at the Connection scope includes all nodes and VMs within that connection.

Tag and Pool Scopes

Tag and pool scopes are resource-flat: instead of granting a branch of the infrastructure, they grant the guests that carry the tag or belong to the resource pool, wherever those guests happen to run. The visible perimeter is then derived from the guests that remain after filtering, so the clusters and nodes hosting them appear only insofar as they are needed to list those guests, and a cluster left without a single visible guest is dropped from the view.

info

A user whose only grant is a tag or a pool gets the flat guest views: VMs, Tags, Pools, Favorites, and Templates, landing on the one that matches their grant. The Tree and Hosts inventory views, the Topology page, the storage views, and the PBS and external hypervisor entries remain unavailable, because a tag or pool grant covers guests, never host-level data.

Creating a guest from a flat grant

A tag or pool grant names guests, never a connection. Every check that asks "may this caller act on this connection" therefore finds nothing to match, and until v1.4.8 that made the Create VM wizard unusable for such a user even when they held vm.create: the pool and storage pickers came back empty, the node had nothing to offer, and the submit itself was refused.

Since v1.4.8 a caller whose only grants are flat gets a derived perimeter: the connections, nodes and pools of the guests they can already see. It is computed from the same guest set the inventory already sends them, so it never widens what they can reach, and it is resolved from the shared inventory cache alone: if the cache cannot answer, the perimeter is empty and the call is refused rather than allowed.

Six checks of the Create VM and Create Container flows accept that derived perimeter: the resource pool list, the storage list, the network choices, the CPU models of a node, the contents of a storage (the ISO and template picker) and the guest creation itself.

The new guest is then forced into a pool the creator can see, so it cannot be created invisible to the person who created it:

Situation	Result
A pool is named and it is inside the perimeter	Accepted as chosen
A pool is named and it is outside the perimeter	Refused, Resource pool outside your scope
No pool is named and exactly one is accessible	That pool is set on the guest
No pool is named and none, or several, are accessible	Refused, A resource pool within your scope is required

The wizard reflects this: when the pool list comes back restricted and holds a single entry, that entry is preselected.

note

For a vDC tenant, the vDC's own pool still wins over this rule, as it does for every other guest created in a vDC.

Permission Inheritance

RBAC permissions follow a top-down inheritance model:

• Global permissions cascade to all connections, nodes, and VMs
• Connection permissions cascade to all nodes and VMs within that connection
• Node permissions cascade to all VMs on that node
• VM permissions apply only to the specific VM

Tag and pool scopes sit outside this hierarchy. They neither inherit from it nor cascade into it: they match guests directly, by tag or by pool membership, across every node and cluster the user's tenant can reach.

A user's effective permissions are the union of every grant that applies to them, at all applicable scopes: the roles they hold, plus any permission granted to them individually. There is no deny mechanism -- if a permission is not explicitly granted, it is denied by default, and no grant can take away what another one gives.

Assigning Roles to Users

To assign a role to a user:

1. Navigate to Security & Access > Users
2. Select the user you want to modify
3. In the Role dropdown, select the desired role
4. Optionally, configure scope restrictions for the role
5. Click Save Changes

A user is not limited to one role. Scoped assignments are managed from the Assignments tab of Security & Access > RBAC / Roles, where the same user can hold several roles, each with its own scope and its own tenant: an operator on one cluster and a viewer everywhere else, for instance. The assignment dialog greys out a role and target pair the user already holds, so the same grant cannot be made twice. The user list shows one role chip per user, or a N roles chip when their grants do not agree on a single role.

Creating a custom role remains the better answer when a whole class of users needs the same unusual permission set, since stacking assignments is harder to audit than one well-named role.

Color-Coded Roles

Each role can be assigned a color that is displayed as a badge throughout the UI. This provides a quick visual indicator of a user's access level:

• Role badges appear next to user names in the user list
• Role colors are visible in the audit log and activity feeds
• System roles use fixed colors; custom roles can use any color you choose

Audit Trail for Role Changes

All RBAC-related actions are recorded in the Audit Log:

• Role creation, modification, and deletion
• Permission changes within a role
• Role assignments and unassignments to users
• Scope changes for role assignments

This ensures full traceability of access control changes for compliance and security reviews.

Permissions

Access to RBAC management requires the following RBAC permission:

Permission	Description
admin.rbac	Create, edit, and delete roles; manage permission assignments

Required Feature	Edition
rbac	Enterprise