Access Control Model

Introduction to pigsty’s default access control model

PostgreSQL provides two types of access control mechanisms: Authentication and Privileges.

Pigsty comes with a basic access control model that is sufficient to cover most application scenarios.

Role System

Pigsty’s default privilege system includes four default users and four default roles, covering most business scenarios. You can modify the name of the default user through the configuration file, but the name of the default role is not recommended for novice users. If you need to modify the default role name, please supporting modify the default permission logic in the initialization template.

Default Users

Pigsty comes with four default users.

  • superuser (postgres), the owner and creator of the database, consistent with the OS user
  • Replicator user (replicator), the user used for master-slave replication.
  • monitor user (dbuser_monitor), the user used to monitor database metrics.
  • Administrator (dbuser_admin), who performs daily administrative operations and database changes.

Default Roles

Pigsty comes with three default roles.

  • Read-only role (dbrole_readonly): read-only access
  • Read-write role (dbrole_readwrite): read and write, inherits from dbrole_readonly
  • Administrative role (dbrole_admin): performs DDL changes, inherits dbrole_readwrite
  • Offline-access role (dbrole_offline): special read only access. For ETL, slow queries and interactive access (on specific replica instance),.

The following are the seven default users with role-related variables, three of which have dedicated parameter configuration items for the default user.

For security reasons, we do not recommend configuring passwords for DBSU, so pg_dbsu does not have a dedicated password configuration item. However, you can still specify a password for the superuser in pg_default_roles.

Pigsty附带有基本的访问控制模型，足以覆盖绝大多数应用场景。

用户体系

Pigsty的默认权限系统包含四个默认用户与三类默认角色，覆盖绝大多数业务场景。 您可以通过配置文件修改默认用户的名字，但默认角色的名字不建议新手用户修改。 如需修改默认角色名称，请配套修改初始化模板中的默认权限逻辑。

默认用户

Pigsty带有四个默认用户：

  • 超级用户（postgres），数据库的拥有者与创建者，与操作系统用户一致
  • 复制用户（replicator），用于主从复制的用户。
  • 监控用户（dbuser_monitor），用于监控数据库指标的用户。
  • 管理员（dbuser_admin），执行日常管理操作与数据库变更。

默认角色

Pigsty带有三个默认角色：

  • 只读角色（dbrole_readonly）：只读
  • 读写角色（dbrole_readwrite）：读写，继承dbrole_readonly
  • 管理角色（dbrole_admin）：执行DDL变更，继承dbrole_readwrite

相关配置

以下是7个默认用户与角色的相关变量，其中三个默认用户有专门的参数配置项。

出于安全考虑，我们不建议为DBSU配置密码，故pg_dbsu没有专门的密码配置项。 但您仍然可以在pg_default_roles中为超级用户指定密码。

pg_dbsu: postgres                             # os user for database, postgres by default
pg_replication_username: replicator           # system replication user
pg_replication_password: DBUser.Replicator    # system replication password
pg_monitor_username: dbuser_monitor           # system monitor user
pg_monitor_password: DBUser.Monitor           # system monitor password
pg_admin_username: dbuser_admin               # system admin user
pg_admin_password: DBUser.Admin               # system admin password

pg_default_roles:
  - username: dbrole_readonly                 
    options: NOLOGIN                          # role can not login
    comment: role for readonly access         # comment string

  - username: dbrole_readwrite                # sample user: one object for each user
    options: NOLOGIN
    comment: role for read-write access
    groups: [ dbrole_readonly ]               # read-write includes read-only access

  - username: dbrole_admin                    # sample user: one object for each user
    options: NOLOGIN BYPASSRLS                # admin can bypass row level security
    comment: role for object creation
    groups: [dbrole_readwrite,pg_monitor,pg_signal_backend]

  # NOTE: replicator, monitor, admin password are overwritten by separated config entry
  - username: postgres                        # reset dbsu password to NULL (if dbsu is not postgres)
    options: SUPERUSER LOGIN
    comment: system superuser

  - username: replicator
    options: REPLICATION LOGIN
    groups: [pg_monitor, dbrole_readonly]
    comment: system replicator

  - username: dbuser_monitor
    options: LOGIN CONNECTION LIMIT 10
    comment: system monitor user
    groups: [pg_monitor, dbrole_readonly]

  - username: dbuser_admin
    options: LOGIN BYPASSRLS
    comment: system admin user
    groups: [dbrole_admin]

其他

Pgbouncer的操作系统用户将与数据库超级用户保持一致。

Pigsty默认会使用Postgres管理用户作为Pgbouncer的管理用户，使用Postgres的监控用户同时作为Pgbouncer的监控用户。

权限模型

默认情况下，角色拥有的权限如下所示

GRANT USAGE                         ON SCHEMAS   TO dbrole_readonly
GRANT SELECT                        ON TABLES    TO dbrole_readonly
GRANT SELECT                        ON SEQUENCES TO dbrole_readonly
GRANT EXECUTE                       ON FUNCTIONS TO dbrole_readonly
GRANT INSERT, UPDATE, DELETE        ON TABLES    TO dbrole_readwrite
GRANT USAGE,  UPDATE                ON SEQUENCES TO dbrole_readwrite
GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES    TO dbrole_admin
GRANT CREATE                        ON SCHEMAS   TO dbrole_admin
GRANT USAGE                         ON TYPES     TO dbrole_admin

其他业务用户默认都应当属于三种默认角色之一：只读，读写，管理员。

所有用户都可以访问所有Schema，只读用户可以读取所有表，读写用户可以对所有表进行DML操作，管理员可以执行DDL变更操作。

数据库权限

数据库有三种权限：CONNECT, CREATE, TEMP，以及特殊的属主OWNERSHIP。

默认情况下，如果数据库没有配置属主，那么超级用户将会作为数据库的默认OWNER，而所有业务用户都会具有数据库的CONNECT权限。

如果为数据库配置了属主，则数据库的owner为该用户。在这种情况下数据库的CONNECT权限会被回收，只有OWNER可以CONNECT，管理员与OWNER也可以将CONNECT权限授予其他角色。这种设置对于多租户实例尤为实用。

创建新对象

默认情况下，出于安全考虑，Pigsty会撤销PUBLIC用户在数据库下CREATE新模式的权限，同时也会撤销PUBLIC用户在public模式下创建新关系的权限。数据库超级用户与管理员不受此限制，他们总是可以在任何地方执行DDL变更。

我们非常不建议使用业务用户执行DDL变更，因为PostgreSQL的ALTER DEFAULT PRIVILEGE仅针对“由特定用户创建的对象”生效，默认情况下超级用户postgres和dbuser_admin创建的对象拥有默认的权限配置，如果您希望授予业务用户dbrole_admin，请在执行DDL变更时首先执行

SET ROLE dbrole_admin; -- dbrole_admin 创建的对象具有正确的默认权限

多租户管理

如果您希望简单的使用数据库，那么在pg_databases中将owner留空即可，所有新创建的业务用户都可以连接至该数据库。

如果您希望在单个实例中承载多个数据库（尽管非常不建议这样做），则可以为数据库配置特定的属主。 在这种情况下，默认只有该属主用户可以连接至该数据库，且该属主可以将连接权限授予其他用户。

pg_databases:
  - {name: testdb , owner: dbuser_test} # 去掉owner

在数据库中创建对象的权限与用户是否为数据库属主无关，这只取决于创建该用户时是否为该用户赋予管理员权限。

pg_users:
  - {username: test1, password: xxx , groups: [dbrole_readwrite]}  # 不能创建Schema与对象
  - {username: test2, password: xxx , groups: [dbrole_admin]}      # 可以创建Schema与对象

认证模型

HBA是Host Based Authentication的缩写，可以将其视作IP黑白名单。

HBA配置方式

在Pigsty中，所有实例的HBA都由配置文件生成而来，最终生成的HBA规则取决于实例的角色（pg_role） Pigsty的HBA由下列变量控制：

  • pg_hba_rules: 环境统一的HBA规则
  • pg_hba_rules_extra: 特定于实例或集群的HBA规则
  • pgbouncer_hba_rules: 链接池使用的HBA规则
  • pgbouncer_hba_rules_extra: 特定于实例或集群的链接池HBA规则

每个变量都是由下列样式的规则组成的数组：

- title: allow intranet admin password access
  role: common
  rules:
    - host    all     +dbrole_admin               10.0.0.0/8          md5
    - host    all     +dbrole_admin               172.16.0.0/12       md5
    - host    all     +dbrole_admin               192.168.0.0/16      md5

基于角色的HBA

role = common的HBA规则组会安装到所有的实例上，而其他的取值，例如（role : primary）则只会安装至pg_role = primary的实例上。 因此用户可以通过角色体系定义灵活的HBA规则。

在默认配置下，主库与从库会使用以下的HBA规则：

  • 超级用户通过本地操作系统认证访问
  • 其他用户可以从本地用密码访问
  • 复制用户可以从局域网段通过密码访问
  • 监控用户可以通过本地访问
  • 所有人都可以在元节点上使用密码访问
  • 管理员可以从局域网通过密码访问
  • 所有人都可以从内网通过密码访问
  • 读写用户（生产业务账号）可以通过本地（链接池）访问 （部分访问控制转交链接池处理）
  • 在从库上：只读用户（个人）可以从本地（链接池）访问。 （意味主库上拒绝只读用户连接）
#==============================================================#
# Default HBA
#==============================================================#
# allow local su with ident"
local   all             postgres                               ident
local   replication     postgres                               ident

# allow local user password access
local   all             all                                    md5

# allow local/intranet replication with password
local   replication     replicator                              md5
host    replication     replicator         127.0.0.1/32         md5
host    all             replicator         10.0.0.0/8           md5
host    all             replicator         172.16.0.0/12        md5
host    all             replicator         192.168.0.0/16       md5
host    replication     replicator         10.0.0.0/8           md5
host    replication     replicator         172.16.0.0/12        md5
host    replication     replicator         192.168.0.0/16       md5

# allow local role monitor with password
local   all             dbuser_monitor                          md5
host    all             dbuser_monitor      127.0.0.1/32        md5


#==============================================================#
# Common HBA
#==============================================================#
#  allow meta node password access
host    all     all                         10.10.10.10/32      md5

#  allow intranet admin password access
host    all     +dbrole_admin               10.0.0.0/8          md5
host    all     +dbrole_admin               172.16.0.0/12       md5
host    all     +dbrole_admin               192.168.0.0/16      md5

#  allow intranet password access
host    all             all                 10.0.0.0/8          md5
host    all             all                 172.16.0.0/12       md5
host    all             all                 192.168.0.0/16      md5

#  allow local read-write access (local production user via pgbouncer)
local   all     +dbrole_readwrite                               md5
host    all     +dbrole_readwrite           127.0.0.1/32        md5


#==============================================================#
# primary HBA
#==============================================================#

#==============================================================#
# replica HBA
#==============================================================#
#  allow read-only user (stats, personal) password directly access
local   all     +dbrole_readonly                               md5
host    all     +dbrole_readonly           127.0.0.1/32        md5


#==============================================================#
# Ad Hoc HBA
#==============================================================#
Last modified 2021-02-08: update en deploy doc (c50b13b)