Learn Proxmox VE - User Management, Permissions & Two-Factor Authentication (2FA)

#Introduction

A cluster with unsupervised access is a dangerous cluster. One leaked root account can destroy your entire infrastructure within minutes. Episode 14 teaches you how to arrange who can access what — the foundation of professional security.

We'll get to know the authentication realms, break down Role-Based Access Control (RBAC) with built-in and custom roles, understand permission paths, and then enable two-factor authentication for important accounts. By the end of the episode, you'll no longer be sharing the root password with the whole team.

#Authentication Realms

#The Types of Realms

A realm is the authentication source — where user identity is verified. Proxmox supports several realms:

PAM: uses Linux users on the node — including root and system users.
PVE: internal Proxmox users stored in its own database.
LDAP/AD: integration with Active Directory or OpenLDAP for large organizations.
OpenID Connect: modern single sign-on, compatible with Keycloak, Google, or other providers.

User format with realm

user@realm  ->  example: admin@pve, root@pam

The user format always includes the realm. This is important when managing permissions.

#When to Use Which Realm

For a single node and homelab, the PVE realm is enough. When the team grows or you already have Active Directory, integrate LDAP so users are centralized. If the organization uses modern SSO, choose OpenID Connect. The bigger the organization, the more important centralized authentication becomes.

#Role-Based Access Control (RBAC)

#Proxmox Built-in Roles

RBAC separates identity (who) from access rights (what they're allowed to do). Proxmox provides built-in roles:

PVEAdmin: full control over all resources.
PVEAudit: view-only, without the ability to change.
PVEVMUser: can manage specific VMs according to their permission paths.

Create a user and assign a role

pveum user add dev@pvem --password
pveum aclmod /vms/100 -user dev@pvem -role PVEVMUser

The pveum user add command creates an internal user, and pveum aclmod gives that user the PVEVMUser role on the /vms/100 path — meaning they can only manage VM 100.

#Custom Roles

If the built-in roles aren't precise enough, create a custom role with the combination of privileges you want. For example, a BackupOperator role that only has backup and restore privileges. This customization ensures the least privilege principle: give the minimum rights needed for a specific job.

#Permission Paths

#The Permission Hierarchy

Permissions in Proxmox are granted on paths that form a hierarchy, and rights granted at an upper path flow down to lower paths:

/ : the entire datacenter.
/nodes/<node> : a single node.
/vms/<id> : a single VM or container.
/pool/<pool> : a group of VMs.

Permission hierarchy

/ (datacenter) -> /nodes/pve -> /vms/100

With this structure, you can give broad access to one team and narrow access to others — all from the same console.

#Applying RBAC in Practice

A real-world example: a team with three different roles.

Infra team: the PVEAdmin role on the / path — full access.
Developer: the PVEVMUser role on the /vms/100 and /vms/101 paths — can only manage specific VMs.
Auditor: the PVEAudit role on the / path — view-only.

Apply RBAC in layers

pveum aclmod / -user infra@pve -role PVEAdmin
pveum aclmod /vms/100 -user dev@pve -role PVEVMUser
pveum aclmod / -user auditor@pve -role PVEAudit

The pveum aclmod command applies permissions according to the path. This pattern ensures each person only sees and changes what falls under their responsibility.

#Two-Factor Authentication (2FA)

#TOTP and WebAuthn

Passwords alone aren't enough in the era of phishing attacks. Proxmox supports two 2FA methods:

TOTP: codes that change every 30 seconds from apps like Google Authenticator or Authy.
WebAuthn (FIDO2): uses hardware keys like YubiKey, or platform authenticators.

#Enabling 2FA in the Web UI

Enable 2FA at Datacenter -> Permissions -> Two-Factor Authentication. Choose the TOTP or WebAuthn method, then follow the wizard: scan the QR code for TOTP, or plug in the hardware key for WebAuthn.

2FA activation flow

Choose a method -> scan QR / plug in the key -> enter the verification code -> done

Once enabled, the next login asks for a TOTP code or key interaction. Enforce 2FA for all accounts with administrative access.

Warning

Save your recovery keys and don't lose your 2FA devices. If the root account gets locked out, you'll have to go through the node's physical console with PAM access to recover access.

#Closing

Episode 14 organized access to your cluster: understanding authentication realms, using RBAC with built-in and custom roles, arranging permission paths from the datacenter down to individual VMs, and enabling TOTP and WebAuthn 2FA.

The key takeaways:

Realms determine the authentication source: PAM, PVE, LDAP, or OpenID Connect.
The user format always includes the realm, e.g. admin@pve.
RBAC separates users, roles, and permission paths.
Apply least privilege with custom roles.
Permissions flow down from upper to lower paths.
Enable 2FA for all administrative accounts.

In the next episode, episode 15, we will cover Proxmox node security hardening — disabling SSH password login, changing the SSH port, using valid TLS certificates, restricting web UI access to a management VLAN, and automating security updates. Your access is now structured; it's time to harden the node itself!