Configuration of PostgreSQL Operator RBAC

PostreSQL Operator RBAC

The conf/postgres-operator/pgorole file is read at start up time when the operator is deployed to the Kubernetes cluster. This file defines the PostgreSQL Operator roles whereby PostgreSQL Operator API users can be authorized.

The conf/postgres-operator/pgouser file is read at start up time also and contains username, password, role, and namespace information as follows:

username:password:pgoadmin:
pgouser1:password:pgoadmin:pgouser1
pgouser2:password:pgoadmin:pgouser2
pgouser3:password:pgoadmin:pgouser1,pgouser2
readonlyuser:password:pgoreader:

The format of the pgouser server file is:

<username>:<password>:<role>:<namespace,namespace>

The namespace is a comma separated list of namespaces that user has access to. If you do not specify a namespace, then all namespaces is assumed, meaning this user can access any namespace that the Operator is watching.

A user creates a .pgouser file in their $HOME directory to identify themselves to the Operator. An entry in .pgouser will need to match entries in the conf/postgres-operator/pgouser file. A sample .pgouser file contains the following:

username:password

The format of the .pgouser client file is:

<username>:<password>

The users pgouser file can also be located at:

/etc/pgo/pgouser

or it can be found at a path specified by the PGOUSER environment variable.

If the user tries to access a namespace that they are not configured for within the server side pgouser file then they will get an error message as follows:

Error: user [pgouser1] is not allowed access to namespace [pgouser2]

If you wish to add all avaiable permissions to a pgorole, you can specify it by using a single * in your configuration. Note that if you are editing your YAML file directly, you will need to ensure to write it as "*" to ensure it is recognized as a string.

The following list shows the current complete list of possible pgo permissions that you can specify within the pgorole file when creating roles:

Permission	Description
ApplyPolicy	allow pgo apply
Cat	allow pgo cat
CreateBackup	allow pgo backup
CreateBenchmark	allow pgo create benchmark
CreateCluster	allow pgo create cluster
CreateDump	allow pgo create pgdump
CreateFailover	allow pgo failover
CreatePgbouncer	allow pgo create pgbouncer
CreatePolicy	allow pgo create policy
CreateSchedule	allow pgo create schedule
CreateUpgrade	allow pgo upgrade
CreateUser	allow pgo create user
DeleteBackup	allow pgo delete backup
DeleteBenchmark	allow pgo delete benchmark
DeleteCluster	allow pgo delete cluster
DeletePgbouncer	allow pgo delete pgbouncer
DeletePolicy	allow pgo delete policy
DeleteSchedule	allow pgo delete schedule
DeleteUpgrade	allow pgo delete upgrade
DeleteUser	allow pgo delete user
DfCluster	allow pgo df
Label	allow pgo label
Load	allow pgo load
Ls	allow pgo ls
Reload	allow pgo reload
Restore	allow pgo restore
RestoreDump	allow pgo restore for pgdumps
ShowBackup	allow pgo show backup
ShowBenchmark	allow pgo show benchmark
ShowCluster	allow pgo show cluster
ShowConfig	allow pgo show config
ShowPolicy	allow pgo show policy
ShowPVC	allow pgo show pvc
ShowSchedule	allow pgo show schedule
ShowNamespace	allow pgo show namespace
ShowUpgrade	allow pgo show upgrade
ShowWorkflow	allow pgo show workflow
Status	allow pgo status
TestCluster	allow pgo test
UpdateCluster	allow pgo update cluster
User	allow pgo user
Version	allow pgo version

If the user is unauthorized for a pgo command, the user will get back this response:

Error:  Authentication Failed: 403

Making Security Changes

Importantly, it is necesssary to redeploy the PostgreSQL Operator prior to giving effect to the user security changes in the pgouser and pgorole files:

make deployoperator

Performing this command will recreate the pgo-config ConfigMap that stores these files and is mounted by the Operator during its initialization.