Proxmox Security Hardening: Practical Implementation Guide

Proxmox VE often serves as the virtualization backbone for labs, edge sites, and production clusters. That makes security hardening a first-order task, not an afterthought. This guide gives you practical steps and copy-paste examples to lock down access, protect secrets, tighten permissions, reduce network exposure, and verify changes safely. By the end you will have a clear workflow, a small pilot you can run locally, and a repeatable process to scale the changes across clusters.

Workflow Overview

Follow this sequence to keep changes safe and understandable:

1. Baseline

• Inventory nodes, Proxmox versions, and enabled services.
• Record who can log in, how, and from where.

1. Access control

• Move away from shared root access.
• Create per-user accounts, groups, and roles.
• Enforce 2FA for interactive logins; scope API tokens for automation.

1. Secrets and permissions

• Store secrets in private locations with least privilege.
• Rotate and audit tokens and keys.

1. OS and Proxmox surface

• Patch regularly; restrict SSH and web UI exposure.
• Enable Proxmox firewall and VM firewalls with allow-lists.

1. Network segmentation

• Place management on a dedicated VLAN or subnet.
• Isolate storage (e.g., Ceph) and VM networks.

1. Backup safety

• Use encrypted backups and test restores.

1. Validate

• Test logins, backup jobs, and VM operations.
• Monitor logs and metrics for regressions.

1. Roll out

• Pilot on a single node, then apply to the cluster with change windows.

Access Control Basics

Create individual users and assign roles via groups. Avoid daily use of root@pam for the web UI or API.

Create an admins group and a user

pveum group add admins -comment "Proxmox admins"
pveum user add alice@pve
pveum passwd alice@pve

Grant the group a role at the root path

pveum aclmod / -group admins -role Administrator

Tips

• Use built-in roles (e.g., PVEAdmin for broad admin tasks, PVEAuditor for read-only). Apply them to the smallest applicable path — a pool, node, storage, or specific VM — not always /.
• Enforce 2FA for the user realm (TOTP or WebAuthn) from Datacenter → Authentication. Require it for all interactive logins.
• Prefer per-user API tokens for automation: create a token for a user, assign the minimal role on the specific path it needs, and avoid wide-scoped roles at /.
• Avoid sharing credentials. If a token leaks, rotate it and check logs.

Secrets and Permissions

Scope and store secrets carefully.

API tokens

• Create distinct tokens per tool or job (e.g., ci-backup, monitoring).
• Limit each token to the paths it needs. Example: a backup token gets permissions only on the storage and VMs it backs up.
• Set an expiration date and rotate on a schedule. Remove unused tokens.
• Example: create a token for a backup user with access only to the backup-storage storage and the production pool:

  pveum user token add backup-user@pve backup-token --privsep 0 --expire 2025-12-31
  pveum aclmod /pool/production -token backup-user@pve!backup-token -role PVEVMAdmin
  pveum aclmod /storage/backup-storage -token backup-user@pve!backup-token -role PVEDatastoreUser

Backup encryption

• When using Proxmox Backup Server (PBS), enable client-side encryption for backup jobs.
• Protect the encryption key: keep an offline copy in a secure vault, and restrict filesystem permissions to root on the node where it is stored (chmod 600 /etc/proxmox-backup/encryption-key.pem).
• Add a periodic test restore to confirm the key and backups are usable.

File permissions

• Keep sensitive files readable only by root. Use chmod 600 and chown root:root for key material where applicable.
• Avoid placing secrets in shared storage that is broadly readable across nodes unless required and protected.

Auditing

• Periodically list users, groups, roles, and ACLs with pveum commands and compare to an approved baseline.

Network Exposure

Reduce the attack surface by limiting what is reachable and from where.

Management network

• Bind the web UI (port 8006) and SSH to a management VLAN or subnet.
• Allow access only from admin IP ranges or a bastion host.

Proxmox firewall

• Enable firewall globally at Datacenter → Firewall and per node at Node → Firewall.
• Default inbound policy: drop, with explicit allow rules for SSH (22/tcp) and web UI (8006/tcp) from admin ranges.
• Enable the VM firewall and use security groups (rule groups) for common patterns (e.g., allow_ssh_from_admins).

TLS

• Use proper TLS certificates for the web UI. Proxmox supports ACME to obtain certs automatically.

SSH hardening

Edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Reload SSH:

systemctl reload ssh

• Use per-user keys and sudo for escalation.

Cluster and storage traffic

• Keep corosync and storage (e.g., Ceph) traffic on dedicated networks. Do not expose them to the internet.

External exposure

• Avoid publishing the Proxmox UI directly to the internet. If remote access is needed, use a VPN and IP allow-lists.

Safe Hardening Checks

Verify without breaking operations.

Access checks

• Confirm that admins can log in with 2FA and perform required tasks.
• Validate that least-privilege users see only their assigned resources.

Network checks

• From an admin workstation, verify you can reach 8006/tcp and 22/tcp.
• From non-admin networks, confirm ports are blocked.
• On nodes, list listeners and bindings:

  ss -tulpen | grep -E "):(22|8006)"

Firewall checks

• Confirm that the datacenter and node firewalls show enabled in the UI.
• Test a temporary deny rule and remove it after validation.

Backup and restore

• Run a backup job and perform a file-level or full restore test to a scratch VM.
• Confirm encryption works and keys are accessible.

Audit and logs

• Review recent auth and API events. Spot unexpected sources or failed logins.
• Keep a short runbook entry for each hardening change and its rollback.

Local Pilot Plan

Pilot on one non-critical node or lab cluster and measure results.

Scope (narrow and testable)

• Users and 2FA: create per-user accounts, enable 2FA, disable root UI login.
• SSH: disable password auth and direct root SSH, verify key-based admin access.
• Firewall: enable datacenter and node firewalls, allow only admin subnets to 22 and 8006.
• Backups: enable encryption for one backup job and test a restore.

Steps

1. Baseline: capture current users, ACLs, open ports, and backup status.
2. Implement: apply the four items above with change notes.
3. Validate: run the checks in the Safe Hardening Checks section.
4. Measure: record time-to-login, failed login attempts, blocked ports, and a successful restore.
5. Decide: if stable for a week, schedule rollout to the next node.

Roll-forward criteria

• All admins can log in with 2FA.
• SSH access via keys works for on-call staff.
• UI and SSH blocked from non-admin networks.
• Backup restore completes successfully.

Rollback plan

• Keep console access ready (IPMI or hypervisor console).
• Maintain a known-good sshd_config and firewall snapshot to reapply if needed.

Conclusion

Proxmox hardening pays off quickly when you apply a clear, staged approach. Lock down accounts with 2FA and least privilege, protect secrets and tokens, limit network exposure with a deny-by-default firewall, and verify with small, safe checks. Start with the local pilot, measure the outcomes, and then roll out across nodes with confidence. Your next actions today: create per-user accounts, enable 2FA, restrict UI and SSH to your admin network, and run a test restore. That foundation will carry you into deeper controls like segmented storage networks and continuous audit.