Proxmox VE Security Hardening Guide: Realms, API Tokens, Firewall and Cluster Trust

A Proxmox VE node controls every virtual machine, container, disk image and backup on it, so one stolen root password or over-privileged API token is a whole-estate compromise. Installations built as a proof of concept often reach production with the defaults intact: root@pam used for everything, the management interface on user networks, the firewall off and automation tokens holding full administrator rights. This guide covers how authentication realms, two-factor authentication, roles and ACL paths work, how to scope API tokens used by backup, monitoring and infrastructure-as-code tools, how cluster trust is built on root SSH keys, and the baseline settings for pveproxy, the firewall and the package repositories. It is written for virtualisation administrators and security engineers responsible for Proxmox VE 8 and 9 clusters, and it complements the vendor-neutral Hypervisor and Virtualisation Security Guide.

Key takeaways

• Treat root@pam as break-glass only. The system root account is an unconfined administrator that cannot be deleted; give administrators named accounts in an LDAP, AD or OpenID Connect realm, enforce TOTP or WebAuthn, and keep root for recovery.
• Scope every API token. Tokens use the form USER@REALM!TOKENID; keep privilege separation on (the default), grant the token its own narrow role on the narrowest path, set an expiry and store the secret in a secrets manager, because it is shown only once.
• Keep the management plane off user networks. Port 8006 (web UI and API), 22 (SSH), 5900-5999 (VNC console) and 3128 (SPICE proxy) belong on a dedicated management network, enforced with the management IP set, ALLOW_FROM in /etc/default/pveproxy and an upstream firewall.
• Cluster trust is root SSH trust. Every node shares a cluster-wide root authorized_keys, so compromise of one node is compromise of the cluster; remove stale node keys, keep corosync and migration on separate networks and use secure migration.
• Backups are the recovery plan and a target. Use Proxmox Backup Server client-side encryption with the key held off the hypervisor, a scoped backup token instead of root, and restore tests, so ransomware on the hosts cannot also destroy recovery.

How identity and access work in Proxmox VE

Every Proxmox VE user ID has the form user@realm. The realm decides where the password is checked; permissions are always held in Proxmox VE itself and are replicated to every node through the cluster file system mounted at /etc/pve. Realm definitions are stored in /etc/pve/domains.cfg.

Two-factor authentication

• TOTP: users can enrol it themselves, or a realm can enforce it for all its users. After 8 failed TOTP attempts the TOTP factors are locked; recovery keys unlock them, or an administrator runs pveum user tfa unlock <user>.
• WebAuthn: phishing-resistant and the preferred factor for administrators. It needs a trusted HTTPS certificate and WebAuthn settings under Datacenter, Options (stored in /etc/pve/datacenter.cfg). Changing those settings later can invalidate existing registrations, so set the relying party ID to its final name before enrolment.
• Recovery keys: single-use, one set per user. Issue them to administrators and store them like break-glass credentials.

For an openid realm, enforce MFA at the identity provider rather than in Proxmox VE. See the Passwordless and Passkeys Guide for choosing phishing-resistant factors.

Admin roles and privileged access

Permissions are assigned as an ACL entry: a user, group or token, a role, and a path. Paths form a tree: /, /vms and /vms/{vmid}, /storage/{storeid}, /nodes/{node}, /pool/{poolname}, /access/groups and /access/realms/{realmid}. The propagate flag is set by default, deeper paths override inherited permissions, individual user permissions override group permissions, and the NoAccess role cancels all other roles on a path.

• Sensitive privileges: the documentation flags Permissions.Modify and Sys.Modify as sensitive. Anyone holding Permissions.Modify on a path can grant themselves more, so audit it like domain admin rights. VM.Console gives keyboard access to guests and should be granted deliberately.
• Use pools for delegation: group VMs and datastores in a pool and grant roles on /pool/{poolname}, for example pveum acl modify /pool/dev-pool/ -group developers -role PVEAdmin, so new VMs inherit the right access.
• Break-glass: the root account can always log in through the PAM realm. Give it a long unique password (the installer accepts 8 characters; the documentation recommends at least 12), vault it, and alert on every root@pam web login. See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Backup, Terraform, Ansible, monitoring and VDI tools authenticate to the REST API on https://<node>:8006/api2/json/. Each is a non-human identity with hypervisor-level access. Interactive users get a ticket in the PVEAuthCookie cookie with a 2-hour lifetime (write requests also need the CSRFPreventionToken header; tickets are signed with a cluster-wide key rotated daily). Automation should instead use API tokens, sent as Authorization: PVEAPIToken=USER@REALM!TOKENID=UUID.

• Scope example: a monitoring token needs only read access, created with pveum user token add svc-monitor@pve metrics -privsep 1 and granted PVEAuditor on / or on /vms. A Terraform token for one team's pool needs VM and datastore allocation rights on that pool, not Administrator on /.
• Do not leak tokens on the command line: the API documentation notes that command-line passwords and headers are visible to other users on the system, and recommends keeping headers in a user-only file passed with curl -H @file. Production clients should validate the certificate rather than use --insecure.
• Proxmox Backup Server: the backup client accepts a token as --auth-id user@realm!tokenname with the secret in PBS_PASSWORD (or PBS_PASSWORD_FILE, PBS_PASSWORD_FD, PBS_PASSWORD_CMD). PBS_AUTH_ID defaults to root@pam, so set it explicitly.
• Inventory: list tokens per user with pveum user token list <user> and record each in the service account inventory with owner, purpose, scope and expiry. See the API Key Management Guide and the Service Account Security Guide.

Cluster trust, SSH and network separation

Proxmox VE clusters rely on SSH between nodes on TCP 22 for cluster actions, and root's authorized_keys is linked to a cluster-wide file, /etc/pve/priv/authorized_keys. The cluster documentation also states that sshd is configured to allow root login with a password. Root on any node can therefore reach every node, and anything in the cluster file system is shared.

• Restrict SSH: allow SSH only from the management network and other nodes, and test node joins and migrations after any change. See the OpenSSH Server Hardening Guide.
• Remove departed nodes: after pvecm delnode, the removed node's public key stays in /etc/pve/priv/authorized_keys; delete it.
• Corosync: uses UDP 5405-5412 and should run on a dedicated physical NIC, not shared with storage. Modern Kronosnet transport supports authentication and encryption (secauth: on appears in the documented configuration); legacy transports disable all cryptography.
• Live migration: set migration: secure,network=<cidr> in /etc/pve/datacenter.cfg. The insecure type sends guest RAM unencrypted, which can include keys and passwords held in memory.

Logging and detection

• Sources: the systemd journal on each node (journalctl) holds pveproxy, pvedaemon, sshd and cluster service messages; the GUI shows per-node syslog and the cluster task log, which records who started, stopped, migrated, backed up or deleted each guest. Forward it to a SIEM: root on the node can edit local logs.
• Authentication events: alert on failed and successful web logins for root@pam, logins from outside the management range, TOTP lockouts, new TFA registrations and API token use from unexpected source addresses.
• Configuration changes: alert on changes to /etc/pve/user.cfg (users, tokens and ACLs), /etc/pve/domains.cfg, /etc/pve/firewall/*.fw, /etc/pve/datacenter.cfg and /etc/pve/priv/authorized_keys. File integrity monitoring or auditd watches on the node work; see the Linux Logging and auditd for Defenders Guide.
• Destructive actions: mass guest stop, snapshot deletion, backup job removal, datastore removal and prune changes on the backup server are classic pre-encryption steps (ATT&CK T1490 Inhibit System Recovery before T1486 Data Encrypted for Impact). The ESXi Ransomware Playbook describes the same pattern on another hypervisor.

Hardening baseline

There is no CIS Benchmark specific to Proxmox VE at the time of writing, so build the baseline from the vendor documentation and apply the Debian or general Linux benchmark to the host operating system where it does not conflict with cluster functions. See the Linux Server Hardening Guide for the operating system layer.

1. Repositories and updates: production should use the enterprise repository (pve-enterprise, which needs a subscription) or at least pve-no-subscription; the documentation says no-subscription is not recommended for production, and pve-test is only for testing. Packages are signed with /usr/share/keyrings/proxmox-archive-keyring.gpg, maintained by the proxmox-archive-keyring package; do not disable signature checks. Patch nodes one at a time after migrating guests away. See the Linux Package Signing and Repository Trust Guide.
2. Restrict pveproxy: in /etc/default/pveproxy set ALLOW_FROM to the management ranges, DENY_FROM="all" and POLICY="allow" (the documented pattern where allow entries win), then systemctl restart pveproxy.service spiceproxy.service. Avoid LISTEN_IP on clustered nodes, as the documentation advises. Consider COMPRESSION=0, which the documentation describes as a BREACH-class mitigation.
3. Certificates: replace the self-signed certificate with one from your internal CA or ACME, installed as /etc/pve/local/pveproxy-ssl.pem and pveproxy-ssl.key (the key must not have a passphrase). A trusted certificate is also a precondition for WebAuthn and lets API clients stop using insecure flags.
4. Enable the firewall: set enable: 1 in the [OPTIONS] section of /etc/pve/firewall/cluster.fw (disabled by default). Populate the management IP set first so the generated rules keep GUI, VNC, SPICE and SSH access for admins, and keep a console path open while testing. Use the blacklist IP set for known bad sources.
5. Guest firewalls: enable per VM (enable: 1 in /etc/pve/firewall/<VMID>.fw) and on each virtual NIC; turn on ipfilter to stop IP spoofing, keep macfilter on (default) and use cluster-level security groups for common rule sets. The nftables backend (proxmox-firewall) is documented as a technology preview, so check its status before relying on it for forward or VNet rules.
6. Identities: create a directory or OIDC realm, enforce TFA, create admin groups with ACLs on /, delegate everything else through pools, and create one service user and separated token per integration.
7. Network separation: management, corosync, storage, migration and guest traffic on separate networks or VLANs; secure migration only.
8. Backups: create the encryption key with proxmox-backup-client key create, import a master public key so each backup carries an RSA-encrypted copy of the key, and store the key and a paperkey printout off the hypervisor. Without the key, backups are unrecoverable. Keep the backup server administered by different identities from the hypervisors. See the Backup Identity Isolation Guide.
9. Roll back safely: every change in this list is held in /etc/pve or /etc/default/pveproxy; copy the files before each change, apply to one node or one test cluster first, and keep out-of-band console access (IPMI, iDRAC, iLO on its own isolated network) to undo a firewall lockout.

Common misconfigurations

• Management interface on the user or internet-facing network: port 8006 reachable from anywhere puts the API and the root password one guess or one vulnerability away from attack (T1190 Exploit Public-Facing Application).
• Automation running as root@pam: Terraform, backup and monitoring tools configured with the root password, so any leak of a CI variable or state file gives full cluster control.
• Tokens with privilege separation disabled: a token created for a convenience script inherits Administrator from its user and never expires.
• Firewall enabled without the management IP set: administrators lock themselves out, then disable the firewall permanently instead of fixing the rule.
• Backups on the same trust domain: backup storage mounted on the hypervisors with the same root credentials, so the attacker who encrypts the VMs deletes the backups first.
• Stale cluster keys and accounts: removed nodes still trusted in authorized_keys, and pve realm users of departed staff still enabled because no directory lifecycle applies to them.

Decision guidance and framework mapping

• Small sites (one to three nodes): a pve realm with enforced TFA, the firewall with a management IP set, encrypted backups to a separate backup server and one scoped token per tool. Keep root@pam and one pve break-glass account even where people use a directory realm.
• Large or regulated estates: an OpenID Connect realm with MFA at the identity provider, group-based ACLs from directory sync, access through a PAM jump host, central alerting and token issuance through a secrets manager.

Metrics that show the baseline is working: number of identities holding Administrator or Permissions.Modify on / (target: the admin group only); percentage of human accounts with TFA (target 100%); percentage of API tokens with privilege separation and an expiry (target 100%); count of root@pam web logins per month outside declared break-glass events (target zero); nodes reachable on 8006 from non-management networks (target zero, tested by an external scan); and days since the last successful test restore from an encrypted backup.

Practitioner checklist

• Move administrators to an LDAP, AD or OpenID Connect realm with enforced TFA, preferring WebAuthn; vault the root@pam password and alert on its use.
• Review effective rights with pveum user permissions; limit Administrator, Permissions.Modify and Sys.Modify to a small group.
• Delegate guest administration through pools and custom least-privilege roles.
• Give each integration its own service user and a privilege-separated token with an expiry; store secrets in a secrets manager and record them in the NHI inventory.
• Set ALLOW_FROM, DENY_FROM and POLICY in /etc/default/pveproxy, install a trusted certificate and enable the cluster firewall with a populated management IP set.
• Separate management, corosync, storage and migration networks; set secure migration in datacenter.cfg.
• Remove stale keys from /etc/pve/priv/authorized_keys and restrict SSH to nodes and admin hosts.
• Use the enterprise or no-subscription repository with signature checks intact, and patch nodes in rolling order.
• Encrypt backups client-side, keep the key and paperkey off the hypervisors, and run a test restore every quarter.
• Forward journals and task logs to the SIEM and alert on ACL, token, realm, firewall and backup changes.

Standards and references

• Proxmox: User Management (realms, TFA, roles, API tokens)
• Proxmox: Proxmox VE Firewall
• Proxmox: pveproxy, Proxmox VE API Proxy Daemon
• Proxmox: Cluster Manager
• Proxmox: Proxmox VE API
• Proxmox: Backup Client Usage (Proxmox Backup Server)
• Proxmox: Proxmox VE Administration Guide
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Hypervisor and Virtualisation Security Guide · Building a Cybersecurity Home Lab Guide · VMware vCenter Server Hardening Guide · ESXi Ransomware Playbook · Service Account Security Guide