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

> How Proxmox VE authorization works: authentication realms, built-in roles, assigning ACLs to a path, and API tokens.

## 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](https://www.zevshost.net/en/kb/proxmox-2fa-zashchita-paneli/).

## Built-in Roles and Creating a Custom Role

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

| Role | Rights |
| --- | --- |
| PVEAdmin | full control except datacenter settings |
| PVEVMAdmin | manages specific VMs: start, stop, console |
| PVEVMUser | console access and basic VM operations only |
| PVEAuditor | view only, no right to change anything |

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](https://www.zevshost.net/en/kb/proxmox-vm-sozdat/) 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](https://www.zevshost.net/en/kb/proxmox-api-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.

---

Source: https://www.zevshost.net/en/kb/proxmox-polzovateli-roli-acl/