And these backups are on the PBS you gave in PDM or did I miss something? Even with an offsite PBS you would have the same issue: A single pane of glass ( including the offsite PBS ) with the associated riscs or you have backups but no PBS in the PDM
Proxmox (as a company) - what the HELL are you doing? Kernel update to 7 broke networking IN A VM
- Thread starter Kingneutron
- Start date
note that you can configure the token permissions to have only audit access for monitoring, without backup/restore permissions. (I'm not sure about default permissions when pdm is generating the pbs token)
Good point with the permissions, thanks for the hint. I'm not sure either how the defaults are either, When I tried this (with an older PDM and PBS version) the created permissions were very permissive. I might remember wrong though
I also remember that Thomas Lamprecht mentioned in the PDM release thread, that they will release some guidance on securing PDM/PVE/PBS deployments in the future but that part of the doc would still need some time:The PDM is certainly a "lucrative" target due to being a single point of entry to one's whole Proxmox infrastructure, that's actually a big reason for it's a pull based design, i.e., the PDM can be hosted on a secure private location because it will connect to the PVE and PBS hosts, not vice versa. Some how-tos for better practice make sense to have in the midterm, for now I'd recommend blocking all incoming traffic to the PDM that isn't really necessary, using client-side encrypted backups of the PDM host to avoid that access to backups gives access to anything else and potentially also think about using a secure VPN to access remotes through a insecure network (e.g., WireGuard). Making that all a bit more convenient to set up is one of the goals for the midterm though.
Great workOne thing which bothers me: I'm missing documentation on best practices for security and permissions I need to give the API tokens used for the PVE and PBS remotes. Let's say I'm running the datacenter manager and have full admin permissions to the PVE and PBS remotes, then an attacker could take over the PDM instance and also use this to get access to the PVE and PBS infrastructure. Now taking over PVE is not the big deal in my book (yes it might happen, but on the other hand the whole point of the PDM is to have an unified interface for administration so that's a risc...
But even with audit-only permissions you need to allow access to the Port 8007 of the PBS from the PDM. If you disable access to your offsite PBS completly by closing it's port 8007 with iptables/nftables (since pull-syncs on the remote PBS don't need itk), any bad actor can't do anything from the PDM acker even if they know of an exploit for PBS or managed to get the admin credentials from another source (e.g. social engineering, mitm-attack on an admin notebook etc)
Don't get me wrong: Of course you could still use PDM for your local PBS (which already needs to have an open port 8007 because otherwise backups won't work) and limit connections to a dedicated backup or management vpn so only your PVE nodes (for their backup), your PDM and your admin notebooks can acess it. One might also argue that your threat model can accept the riscs coming from host in the same network or location and thus you can live with the riscs of a PBS managed from PDM. But adding your offsite backup server to PDM is only asking for trouble in my book. YMMV
Last edited: