Users, Roles, and ACLs in Proxmox VE: Managing Access Rights

The Proxmox VE Authorization Model: Users, Roles, and Paths

Access in Proxmox VE is built on three concepts: user, role, and path. A user is an account, a role is a set of specific permissions such as "create a VM" or "view the log," and a path is the object the role applies to: the whole datacenter, a specific node, a resource pool, or a single virtual machine.

The combination "user + role + path" is called an ACL entry. Until such an entry exists for a user, that user has no rights at all, even if the account exists and the password is correct. This protects against accidentally granting broad access to new employees.

Authentication Realms: pve, PAM, LDAP, and AD

Proxmox VE supports several password verification sources. The pve realm stores users in the cluster's internal database, PAM uses the Linux system users on the node, and LDAP and Active Directory let you connect a corporate directory instead of maintaining a local password for every administrator.

For most small teams the pve realm is enough: users are created directly in the web interface and do not depend on the node's operating system. For larger infrastructure with dozens of administrators, LDAP is more convenient — revoking access when an employee leaves happens in one place.

How to Create a User and Set a Password

A user is created in Datacenter → Permissions → Users or with a command in the node console.

pveum user add ivan@pve --password
pveum passwd ivan@pve

Right after creation, the user ivan@pve has no rights at all. The next step is to assign a role on the needed path, otherwise logging into the panel will work but the resource list will stay empty. The account should immediately be protected with two-factor authentication.

Built-in Roles and Creating a Custom Role

Proxmox VE ships with a ready set of roles for typical scenarios.

If the built-in roles do not fit, you can build your own from individual privileges in Datacenter → Permissions → Roles, for example allowing only "VM.Console" and "VM.Monitor" for first-line support staff.

How to Assign an ACL to a Path: Datacenter, Pool, VM

An ACL is assigned in Datacenter → Permissions → Add. You specify the path, the user or group, and the role.

• Path / — the rights apply to the entire cluster.
• Path /pool/webteam — the rights apply only to a specific pool's resources.
• Path /vms/101 — the rights apply only to a single virtual machine.

The inheritance rule is simple: a permission at a higher level of the path applies to every nested object unless a different rule is explicitly set for it. This approach works well together with resource pools when creating virtual machines for different clients or departments.

API Tokens for Automation Without a Password

For scripts and external systems, an API token is used instead of a user's password — a separate secret tied to the account, with its own set of rights.

pveum user token add ivan@pve automation --privsep 1
pveum acl modify /vms/101 --tokens 'ivan@pve!automation' --roles PVEVMUser

The --privsep 1 flag means the token does not automatically inherit the user's rights — it only gets what is explicitly assigned through a separate ACL entry. This limits the damage if the token leaks: it will not grant access to the whole cluster. Details on working with tokens from scripts are in the article on the REST API and automation.

Checklist for Safe Access Control

• Every user has an ACL for a specific path, not for the whole cluster without a reason.
• Built-in roles or a custom role with a minimal set of rights are used.
• API tokens are issued with privsep 1 and their own rights.
• Administrator accounts are protected with two-factor authentication.
• The list of users and roles is reviewed regularly as the team changes.

This kind of rights structure makes access audits predictable: you can see who can manage a specific VM or resource pool, and on what basis.