Securing PostgreSQL High Availability and Disaster Recovery
Date Published
Secure the control plane
In a Patroni architecture, etcd and the Patroni REST API influence leadership and therefore deserve the same protection as PostgreSQL. Restrict them to management networks, use mutual TLS where supported, require authentication, and prevent application users from reaching control endpoints. Back up etcd and monitor unexpected changes to the cluster keyspace.
Limit replication privileges
Replication roles should have LOGIN and REPLICATION only, with no superuser or application permissions. Restrict pg_hba.conf to exact node and disaster-recovery networks. Protect replication credentials in root- or service-owned files with strict permissions. Rotate them through a planned rolling process and verify every replica reconnects.
Harden failover endpoints
A floating VIP needs operating-system network privileges, but the manager process should receive only the capability it needs. HAProxy and PgBouncer administration ports must not be public. Health checks should prove role and readiness without exposing sensitive cluster data. Monitor route changes so an unexpected endpoint move becomes an event, not a mystery.
Prevent backup privilege escalation
Backup agents often read every database and access WAL files, making them high-value targets. Run them as dedicated service identities, restrict outbound destinations, protect repository credentials, and use immutable or object-locked copies. A compromised primary must not be able to silently delete every recovery point.
Treat DR as production
Disaster-recovery clusters frequently become insecure because they are considered passive. Apply the same patching, TLS, identity, logging, and vulnerability-management controls as the primary. Test promotion and failback with security validation: verify roles, secrets, certificates, audit pipelines, and network policy before accepting traffic.