PBS integration security

[DerDanilo]

Just tested PBS PVE integration and was wondering if it will be possible to use "username + ssh key/client cert based authentication" instead of "username + password".
Passwords are currently stored in clear text files within the pve configuration folder. I feel uncomfortable using password when pushing pbs backups through the internet, even when using firewall and maybe even a VPN for addtional protection (which slows transfer speed down of course). WireGuard could maybe be used, but have not tested it yet with PBS.

$ pvesm add pbs backup --server 1.2.3.4 --datastore backup --fingerprint 60:.....:ca --username backup@pbs --password 12345
$ cat /etc/pve/priv/storage/backup.pw
$ 12345

Thanks!

 

[H4R0]

The file containing the password can only be read by root. It would not make a difference to use a private key, as it can be read just as the password..

Your concerns are not valid. The connection is end to end encrypted from pve to pbs. AFAIK its using https with tls 1.3 which would not even support private keys. But it uses certificate pinning already.

The only security issue i see in your example is using the password as argument which could be read by other processes, if pbs client does not spawn a new child without the arguments, which would still issue in a race condition. Dont specify the password and it will be read from config file or pass it via environment variables.

 

[DerDanilo]

Sounds reasonable.
One would need a different user for every vps/server/device that should be able to push only its own backups?

 

[H4R0]

Sounds reasonable.
One would need a different user for every vps/server/device that should be able to push only its own backups?

Depends on your setup, you can use the same user for every server, they will only push their own backups.

But if you want to seperate access, it would be better security wise to setup a user per client. This way if a server has a security breach, it can only access its own backup files on the pbs, not others. IMHO that would be somewhat overkill but it would be good practice nevertheless.

Why do you want to push backups over the internet anyway ? Best setup would be to have a local pbs server for main backups and then setup a remote pbs which uses the pull sync feature, this way your remote server pulls data which is much more secure and the clients have no access to it.

 

[DerDanilo]

Why do you want to push backups over the internet anyway ? Best setup would be to have a local pbs server for main backups and then setup a remote pbs which uses the pull sync feature, this way your remote server pulls data which is much more secure and the clients have no access to it.

I agree. There are client setups with multiple VPS/servers offsite, mostly single nodes. Beeing able to back them up with the pbs client would save a lot of effort for the current setup.

 

[H4R0]

I agree. There are client setups with multiple VPS/servers offsite, mostly single nodes. Beeing able to back them up with the pbs client would save a lot of effort for the current setup.

In that case you are better of creating a seperate user per client, especially if those vps/servers are placed at customer site or can otherwise be accessed by third partys. Otherwise you run the risk that someone has access to your whole backup storage and thus infrastructure.

 

[Ovidiu]

I just wanted to add that apparently you can also use API Tokens instead of user/password.

 

[DerDanilo]

In that case you are better of creating a seperate user per client, especially if those vps/servers are placed at customer site or can otherwise be accessed by third partys. Otherwise you run the risk that someone has access to your whole backup storage and thus infrastructure.

According to the permission given by the role "DatastoreBackup" it is supposed to only allow access to the backups that the specific user or token(user) created. Even if the token is linked to a user the token can only access backups that were created with that specific token.

I have not yet verified this but this actually makes some sense if tokens make sense at all. Otherwise one would have to create a set of user + token when tokens should be used.

This way one user could be created per "customer" and then each customer server gets it's own token. This way the customer can restore files or the whole backup himself without interaction by the provider.

 

[fabian]

According to the permission given by the role "DatastoreBackup" it is supposed to only allow access to the backups that the specific user or token(user) created. Even if the token is linked to a user the token can only access backups that were created with that specific token.

I have not yet verified this but this actually makes some sense if tokens make sense at all. Otherwise one would have to create a set of user + token when tokens should be used.

This way one user could be created per "customer" and then each customer server gets it's own token. This way the customer can restore files or the whole backup himself without interaction by the provider.

yes. the associated user can access all backups owned by the user or any of their tokens, but tokens can only access those that have the token as user (unless of course the token and user are higher-privileged, an can for example read the whole datastore anyway irrespective of backup group ownership). the user can also transfer ownership between any of their tokens and the user itself.

 

[DerDanilo]

Thanks for clearing this up. Customers can have a backup user and multiple tokens. This way their admins have access to all backups but the server admins only to their own.