Eliminate postgres user to access barman backups via ssh

[Allan Harry Nielsen]

Hi

As it is recommended to exchange SSH keys between barman server and postgres clients, 

then how can the backup images on the backup server be protected as the postgres user can login as barman user and erase them ?

Maybe obvious but not for me at least.

In my company DBA's should not be able to access the backup server/discipline. 

Regards Allan

[Muhammad Amer Siddique]

Hi Allan, 

Barman also support streaming protocol for backup using pg_basebackup. from version 2.0. I am sure it will solver the access issue until unless there is some other particular requirement to use SSH.

Someone SSH expert might help with ssh key scenarios. 

 

Regards, Amer

--
--
You received this message because you are subscribed to the "Barman for PostgreSQL" group.
To post to this group, send email to pgba...@googlegroups.com
To unsubscribe from this group, send email to
pgbarman+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pgbarman?hl=en?hl=en-GB

---
You received this message because you are subscribed to the Google Groups "Barman, Backup and Recovery Manager for PostgreSQL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pgbarman+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/pgbarman/1fa3aa47-cd3d-41f4-b255-ba1c4ae293d5n%40googlegroups.com.

[Luca Ferrari]

There is no solution, if the DBA has access to the account that, in
turn, has access to the backup machine.
One could play with shells to avoid problems, but it is a matter of time.
The point is: you don't need the postgres user to provide access to
the backup server, rather vice-versqa. On my machines I've the
'postgres' user running the database and the 'backup' user running the
backup. The backup user must have group access to the postgres
PGDATA, allowed since postgres 10.
Otherwise, as others have suggested, streaming replication is a
scenario that does not involve login accounts.

Luca

[Allan Harry Nielsen]

Hi

Thanks for the clarification.

We have switched to streaming replication for now.

/Allan

[brvi...@gmail.com]

This is of my interest as well... having a production system access to backup system is a serious security flaw.

I've been struggling with this for a couple of years already, since we started to use Barman.

Previously, we did the backup on own server using pg_dump, and started the copy from backup server (so backup has access to production, but not contrary).

Regards,

[Luca Ferrari]

On Thu, Jun 17, 2021 at 9:43 PM brvi...@gmail.com <brvi...@gmail.com> wrote:
>
> This is of my interest as well... having a production system access to backup system is a serious security flaw.
> I've been struggling with this for a couple of years already, since we started to use Barman.

Making a replica of your production server and then doing the backup
from the replica instead of the production server could help solvind
the access to the backup machine, at the cost of one another machine
and a replication setup.

Luca

[brvi...@gmail.com]

Yes, I'm already doind backup from replica.
But them replica has acccess to backup, and still a not good idea.

Nevertheless, I've setup streaming in barman, and configures streaming from replica and it's seems to be working really well.

In replica, I've set "archive_mode = on" and '"archive_command='/bin/true' " - so replica has not access to backup server anymore.

It seems the best way to have incremental backups and isolate backup server from production and replicas.

Do you envision any trouble using streaming this way?

Regards,

Edson

[Luca Ferrari]

On Fri, Jun 18, 2021 at 8:29 PM brvi...@gmail.com <brvi...@gmail.com> wrote:
>
> Yes, I'm already doind backup from replica.
> But them replica has acccess to backup, and still a not good idea.

But you can leave the replica in a different zone, with different
accesses from the egress, so the replica is a little more secure.
Indeed, if you need to backup your machine, a connection between the
two machines must exists, so it is a matter of a trade off.

> Nevertheless, I've setup streaming in barman, and configures streaming from replica and it's seems to be working really well.
> In replica, I've set "archive_mode = on" and '"archive_command='/bin/true' " - so replica has not access to backup server anymore.
> It seems the best way to have incremental backups and isolate backup server from production and replicas.

I don't see why you are lying to PostgreSQL about archiving: if barman
is doing streaming replication why are you telling PostgreSQL to
archive logs, when you are not?

Luca

[brvi...@gmail.com]

Well, actually, I wasn't using barman streaming option.

What I had was:

Master => (streaming to...) => Replication => (wal shipping via rsync to...) => Barman

When using rsync, I had to share the PKI for ssh connection between replication server and barman.

Right now, I'm converting my servers to:

Master => (streaming to...) => Replication => (streaming to...) => Barman

Which doesn't requires to have ssh connection - so, my backup server is far more secure.

Thanks!

ER

[Abhijit Menon-Sen]

1. As already discussed in this thread, you can avoid using
`archive_command` and instead use the streaming_archiver, i.e.,
pg_receivewal. This way, no postgres→barman SSH access is required.

2. In theory, even with archive_command, you could use
~barman/.ssh/authorized_keys to restrict what command may be run via
ssh. See the `command` setting in the authorized_keys(5) manpage. You
would have to write your own archive_command though, so it's not
straightforward, and I wouldn't really recommend it. In fact, now that
I think about it, I don't even know why I brought up the possibility
in the first place.

Just use pg_receivewal, and voilà, no ssh.

-- Abhijit