Re: Seeking practice recommendation: is there ever a use case to have two or more superusers?

On Mon, Nov 21, 2022 at 10:40 AM Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:

>
> Consider this wording. It also uses “good practice”.
>
> «
> It is good practice to limit the number of superuser roles that exist in a
> cluster to exactly one: the inevitable bootstrap superuser. This recognizes
> the fact that, once the initial configuration of a cluster has been done
> immediately after its creation (which configuration is done while still in
> self-imposed single-user mode), there are then very few, and infrequent,
> tasks that require the power of the superuser role.
> »
>
> Nobody supports it!
>
> I’m puzzled why the good practice statement about a role with the CREATEDB
> and CREATEROLE attributes earns a place in the doc while nobody at all is
> prepared to make a practice statement about how many superusers is good.
> I’d like very much to understand the critical parts that I’m missing of the
> essential mental model in this general space.
>

My policy would be that no one is supposed to login to the database cluster
using the postgres role. Period. Upon initialization whomever is
responsible for creating the cluster gets their personal user credentials
installed into the cluster as superuser and from that point on never uses
postgres. They will, however, in the interest of business continuity,
create additional superusers for any others who share the superuser
responsibility.

In short, there is very little room to argue against the principle of least
privilege. I don't see where that principle supports "only have one
superuser" nor does it seem better than another security principle:
"everyone must have their own credentials".

I suppose the suggestion I would be willing to consider is: only have the
postgres superuser, never grant superuser to login roles explicitly,
instead if those persons require superuser grant them membership in the
postgres role. Except I don't think that actually works in a desirable way
today. Having multiple roles in service of least-privilege while retaining
users must use personal login credentials is my suggested starting point
absent some more improvements in the authorization systems (or a better
understanding of existing ones by your truly).

So yes I, like everyone else, is going to end up forming their own
generalities. Ideas that I cannot wholly discredit as bad, but that don't
fit into my generality, get the "if the specific circumstances warrant it"
treatment. My own presuppositions ultimately should get the same treatment
by whomever is implementing such policies.

David J.