Fix CIDR mask for replication peer_ip - #1299

[hloeung]

Issue

The replication users' peer_ip CIDR mask is too open. A /0 usually means ALL.

See #1299

Solution

Reduce CIDR mask to a single IP, with /32 which is safest. If not, we can go with something a little more relaxed such as a /24.

Checklist

• I have added or updated any relevant documentation.
• I have cleaned any remaining cloud resources from my accounts.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.75%. Comparing base (6ffe0b4) to head (f89a300).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1317   +/-   ##
=======================================
  Coverage   75.75%   75.75%           
=======================================
  Files          16       16           
  Lines        4187     4187           
  Branches      633      633           
=======================================
  Hits         3172     3172           
  Misses        793      793           
  Partials      222      222           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marceloneppel]

Hi, @hloeung! I'll schedule the investigation of the CI failures for the next pulse, because when trying to do it as a side task, I found that it needs more time.

[hloeung]

Thanks, much appreciated. This isn't so urgent and more of an improvement - from IS's side, we have multiple layers of security already - password authentication which the charm by default uses, OpenStack security group firewalling as well as NGFW / dedicated firewalling in front of the databases we manage.

[taurus-forever]

The changes itself looks OK and logical, but it looks they brake TLS test at least (here):

Exception: Expected command 'grep 'connection authorized: user=rewind database=postgres SSL enabled' /var/snap/charmed-postgresql/common/var/log/postgresql/postgresql-*.log' to succeed instead it failed: 1

So, it looks like PostgreSQL was not able to connect and rewind SQL transactions from peer. It requires careful re-checking before merging.

The self-healing test is also unhappy after the full cluster restart (rewind in place?):

AssertionError: secondary not up to date with the cluster after restarting.

---

CC: @hloeung

I believe the main trouble-maker here is a cluster<->cluster async replication functionality, where IPs can be anything for different cluster. Sure /0 security can be improved, but it looks like it is not as simple as /32 nor /24.