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: - Baseline - Inventory nodes, Proxmox versions, and enabled services. - Record who can log in, how, and from where. - 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. - Secrets and permissions - Store secrets in private locations with least privilege. - Rotate and audit tokens and keys. - OS and Proxmox surface - Patch regularly; restrict SSH and web UI exposure. - Enable Proxmox firewall and VM firewalls with allow-lists. - Network segmentation - Place management on a dedicated VLAN or subnet. - Isolate storage (e.g., Ceph) and VM networks. - Backup safety - Use encrypted backups and test restores. - Validate - Test logins, backup jobs, and VM operations. - Monitor logs and metrics for regressions. - 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 - Baseline : capture current users, ACLs, open ports, and backup status. - Implement : apply the four items above with change notes. - Validate : run the checks in the Safe Hardening Checks section. - Measure : record time-to-login, failed login attempts, blocked ports, and a successful restore. - 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.