Proxmox security hardening with practical examples: practical implementation guide

Proxmox VE is often the backbone of lab, edge, and production virtualization for startups and DevOps teams. 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 checklist to scale the changes across clusters.

Workflow Overview

Follow this sequence to keep changes safe and understandable:

1. Baseline

• Inventory nodes, 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.

Examples:

• Create an admins group:

pveum group add admins -comment "Proxmox admins"

• Create a user and set a password:

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 the built-in roles (e.g., PVEAdmin for broad admin tasks, PVEAuditor for read-only). Apply them to the smallest applicable path, such as a pool, node, storage, or specific VM path, not always "/".
• Enforce 2FA for the user realm (e.g., 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.

• 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.
• 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.

• 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.