On Mon, Nov 21, 2022 at 4:05 PM Bryn Llewellyn <bryn@yugabyte.com> wrote:
I believe that the fact that a superuser's ability to start a session can be limited by what the "hba_file" says is critical here—together with the fact that the ability to edit this file is governed by the regime of O/S users and file privileges. Maybe this is the key to the effectively tamper-proof implementation of the scheme that David recommends. (Having said this, there's always the "set role" backdoor.)
If you are worried about back-doors here you gave the wrong people superuser. That may be unavoidable, but this scheme really isn't about bullet-proofing security. It's about ease of administration and knowing just who all has permission do what on a server by inspecting its role table.
Yes, you should lock-down pg_hba.conf to avoid other people without superuser from being able to easily hack into the system using one of these accounts (admittedly, a decent reason to limit how many there are, but all of them should be equally/maximally secure so it isn't that strong an argument).
