这是本节的多页打印视图。点击此处打印.

安全合规

身份认证、访问控制、加密通信、审计日志，满足等保三级与 SOC2 合规要求。

1: 本地 CA
2: 访问控制

Pigsty 的安全理念

默认安全：开箱即用的安全配置，无需额外设置即可获得基本保护。

渐进配置：企业级用户可根据需求，通过配置逐步增强安全措施。

纵深防御：多层安全机制，即使某一层被突破，仍有其他层保护。

最小权限：只授予用户完成任务所需的最低权限，降低风险。

默认安全配置

Pigsty 默认启用以下安全特性：

特性	默认配置	说明
密码加密	`scram-sha-256`	PostgreSQL 最安全的密码哈希算法
SSL 支持	启用	客户端可选择使用 SSL 加密连接
本地 CA	自动生成	自签名 CA 签发服务器证书
HBA 分层	按来源控制	不同来源使用不同认证强度
角色系统	四层权限	只读/读写/管理员/离线
数据校验	启用	检测存储层数据损坏
审计日志	启用	记录连接和慢查询

可增强配置

通过额外配置可启用更高安全级别：

特性	配置方式	安全等级
密码强度检查	启用 `passwordcheck` 扩展	等保三级
强制 SSL	HBA 使用 `hostssl`	等保三级
客户端证书	HBA 使用 `cert` 认证	金融级
备份加密	配置 `cipher_type`	合规要求
防火墙	配置 `node_firewall_mode`	基础设施

如果您只有一分钟，请记住这张图：

flowchart TB
    subgraph L1["🌐 第 1 层：网络安全"]
        L1A["防火墙 + SSL/TLS 加密 + HAProxy 代理"]
        L1B["谁能连进来？连接是否加密？"]
    end

    subgraph L2["🔑 第 2 层：身份认证"]
        L2A["HBA 规则 + SCRAM-SHA-256 密码 + 证书认证"]
        L2B["你是谁？怎么证明？"]
    end

    subgraph L3["👤 第 3 层：访问控制"]
        L3A["角色系统 + 对象权限 + 数据库隔离"]
        L3B["你能做什么？能访问哪些数据？"]
    end

    subgraph L4["🔒 第 4 层：数据安全"]
        L4A["数据校验 + 备份加密 + 审计日志"]
        L4B["数据完整吗？操作有记录吗？"]
    end

    L1 --> L2 --> L3 --> L4

核心价值：开箱即用的企业级安全配置，默认启用最佳实践，额外配置可达等保三级与 SOC 2 合规要求。

本章内容

章节	说明	核心问题
安全概述	安全能力总览与检查清单	整体安全架构是怎样的？
身份认证	HBA 规则、密码策略、证书认证	如何验证用户身份？
访问控制	角色系统、权限模型、数据库隔离	如何控制用户权限？
加密通信	SSL/TLS、本地 CA、证书管理	如何保护数据传输？
合规清单	等保三级与 SOC2 详细对照	如何满足合规要求？

为什么安全很重要？

数据泄露的代价

flowchart LR
    Breach["💥 数据泄露"]

    subgraph Direct["💰 直接损失"]
        D1["监管罚款<br/>GDPR 可达全球营收 4%"]
        D2["法律诉讼费用"]
        D3["客户赔偿"]
    end

    subgraph Indirect["📉 间接损失"]
        I1["品牌声誉受损"]
        I2["客户信任丧失"]
        I3["业务中断"]
    end

    subgraph Compliance["⚠️ 合规风险"]
        C1["等保三级：责任追究"]
        C2["SOC 2：认证撤销"]
        C3["行业准入：被禁止经营"]
    end

    Breach --> Direct
    Breach --> Indirect
    Breach --> Compliance

默认用户与密码

Pigsty 默认创建以下系统用户：

用户	用途	默认密码	部署后操作
`postgres`	系统超级用户	无密码（仅本地）	保持无密码
`dbuser_dba`	管理员用户	`DBUser.DBA`	必须修改
`dbuser_monitor`	监控用户	`DBUser.Monitor`	必须修改
`replicator`	复制用户	`DBUser.Replicator`	必须修改

# pigsty.yml - 修改默认密码
pg_admin_password: 'YourSecurePassword123!'
pg_monitor_password: 'AnotherSecurePass456!'
pg_replication_password: 'ReplicationPass789!'

⚠️ 重要：生产环境部署后，请立即修改这些默认密码！

角色与权限系统

Pigsty 提供开箱即用的四层角色系统：

flowchart TB
    subgraph Admin["🔴 dbrole_admin（管理员）"]
        A1["继承 dbrole_readwrite"]
        A2["可以创建/删除/修改对象 DDL"]
        A3["适用于：业务管理员、需要建表的应用"]
    end

    subgraph RW["🟡 dbrole_readwrite（读写）"]
        RW1["继承 dbrole_readonly"]
        RW2["可以 INSERT/UPDATE/DELETE"]
        RW3["适用于：生产业务账号"]
    end

    subgraph RO["🟢 dbrole_readonly（只读）"]
        RO1["可以 SELECT 所有表"]
        RO2["适用于：报表查询、数据分析"]
    end

    subgraph Offline["🔵 dbrole_offline（离线）"]
        OFF1["只能访问离线实例"]
        OFF2["适用于：ETL、个人分析、慢查询"]
    end

    Admin --> |继承| RW
    RW --> |继承| RO

创建业务用户

pg_users:
  # 只读用户 - 用于报表查询
  - name: dbuser_report
    password: ReportUser123
    roles: [dbrole_readonly]
    pgbouncer: true

  # 读写用户 - 用于生产业务
  - name: dbuser_app
    password: AppUser456
    roles: [dbrole_readwrite]
    pgbouncer: true

  # 管理员用户 - 用于 DDL 操作
  - name: dbuser_admin
    password: AdminUser789
    roles: [dbrole_admin]
    pgbouncer: true

HBA 访问控制

HBA（Host-Based Authentication）控制"谁可以从哪里连接"：

flowchart LR
    subgraph Sources["连接来源"]
        S1["🏠 本地 Socket"]
        S2["💻 localhost"]
        S3["🏢 内网 CIDR"]
        S4["🛡️ 管理节点"]
        S5["🌐 外网"]
    end

    subgraph Auth["认证方式"]
        A1["ident/peer<br/>OS 用户映射，最安全"]
        A2["scram-sha-256<br/>密码认证"]
        A3["scram-sha-256 + SSL<br/>强制 SSL"]
    end

    S1 --> A1
    S2 --> A2
    S3 --> A2
    S4 --> A3
    S5 --> A3

    Note["📋 规则按顺序匹配<br/>第一条匹配的规则生效"]

自定义 HBA 规则

pg_hba_rules:
  # 允许应用服务器从内网连接
  - {user: dbuser_app, db: mydb, addr: '10.10.10.0/24', auth: scram-sha-256}

  # 强制某些用户使用 SSL
  - {user: admin, db: all, addr: world, auth: ssl}

  # 要求证书认证（最高安全级别）
  - {user: secure_user, db: all, addr: world, auth: cert}

加密通信

SSL/TLS 架构

sequenceDiagram
    participant Client as 🖥️ 客户端
    participant Server as 🐘 PostgreSQL

    Client->>Server: 1. ClientHello
    Server->>Client: 2. ServerHello
    Server->>Client: 3. 服务器证书
    Client->>Server: 4. 客户端密钥
    Client->>Server: 5. 加密通道建立
    Server->>Client: 5. 加密通道建立

    rect rgb(200, 255, 200)
        Note over Client,Server: 🔒 加密数据传输
        Client->>Server: 6. 应用数据（加密）
        Server->>Client: 6. 应用数据（加密）
    end

    Note over Client,Server: ✅ 防止窃听 ✅ 防止篡改 ✅ 验证服务器身份

本地 CA

Pigsty 自动生成本地 CA 并签发证书：

/etc/pki/
├── ca.crt              # CA 证书（公开）
├── ca.key              # CA 私钥（保密！）
└── server.crt/key      # 服务器证书/私钥

⚠️ 重要：请安全备份 ca.key，丢失后需要重新签发所有证书！

合规对照

等保三级（GB/T 22239-2019）

安全要求	Pigsty 默认	可配置达到	说明
身份鉴别唯一性	✅	✅	每个用户唯一标识
口令复杂度	⚠️	✅	启用 passwordcheck
口令定期更换	⚠️	✅	需要运维流程
双因素认证	⚠️	✅	证书 + 密码
访问控制	✅	✅	HBA + 角色系统
最小权限原则	✅	✅	四层角色模型
通信加密	✅	✅	SSL/TLS
审计日志	✅	✅	连接日志 + 慢查询
数据完整性	✅	✅	数据校验和
备份恢复	✅	✅	pgBackRest

SOC 2 Type II

控制点	Pigsty 支持	说明
CC6.1 逻辑访问控制	✅	HBA + 角色系统
CC6.6 传输加密	✅	SSL/TLS
CC7.2 系统监控	✅	Prometheus + Grafana
CC9.1 业务连续性	✅	高可用 + PITR
A1.2 数据恢复	✅	pgBackRest 备份

图例：✅ 默认满足 · ⚠️ 需要额外配置

安全检查清单

部署前

准备强密码（使用密码管理器生成）
规划网络分区（内网/外网 CIDR）
确定 SSL 策略（自签名/外部 CA）

部署后（必做）

修改所有默认密码
验证 HBA 规则符合预期
测试 SSL 连接正常
配置认证失败告警
安全备份 CA 私钥

定期维护

审计用户权限
检查过期账户
更新证书（如需要）
检查审计日志

快速配置示例

生产环境安全配置

# pigsty.yml - 生产环境安全配置示例
all:
  vars:
    # 修改默认密码（必须！）
    pg_admin_password: 'SecureDBAPassword2024!'
    pg_monitor_password: 'SecureMonitorPass2024!'
    pg_replication_password: 'SecureReplPass2024!'

    # 启用密码强度检查
    pg_libs: 'passwordcheck, pg_stat_statements, auto_explain'

    # 自定义 HBA 规则
    pg_hba_rules:
      # 应用服务器
      - {user: app, db: appdb, addr: '10.10.10.0/24', auth: scram-sha-256}
      # 管理员强制 SSL
      - {user: dbuser_dba, db: all, addr: world, auth: ssl}

金融级安全配置

# 金融级配置 - 启用证书认证
pg_hba_rules:
  # 交易系统使用证书认证
  - {user: trade_user, db: trade, addr: world, auth: cert}
  # 其他系统使用 SSL + 密码
  - {user: all, db: all, addr: world, auth: ssl}

# 启用备份加密
pgbackrest_repo:
  minio:
    cipher_type: aes-256-cbc
    cipher_pass: 'YourBackupEncryptionKey'

接下来

深入了解安全配置的细节：

👁️ 安全概述：整体安全架构与检查清单
🔑 身份认证：HBA 规则与密码策略
👤 访问控制：角色系统与权限模型
🔐 加密通信：SSL/TLS 与证书管理
✅ 合规清单：等保三级与 SOC2 详细对照

1 - 本地 CA

Pigsty 带有一套自签名的 CA 公私钥基础设施，用于签发 SSL 证书，加密网络通信流量。

Pigsty 部署默认启用了一些安全最佳实践：使用 SSL 加密网络流量，使用 HTTPS 加密 Web 界面。

为了实现这一功能，Pigsty 内置了本地自签名的 CA ，用于签发 SSL 证书，加密网络通信流量。

在默认情况下，SSL 与 HTTPS 是启用，但不强制使用的。对于有着较高安全要求的环境，您可以强制使用 SSL 与 HTTPS。

本地CA

Pigsty 默认会在初始化时，在 ADMIN节点本机 Pigsty 源码目录（~/pigsty）中生成一个自签名的 CA，当您需要使用 SSL，HTTPS，数字签名，签发数据库客户端证书，高级安全特性时，可以使用此 CA。

因此，每一套 Pigsty 部署使用的 CA 都是唯一的，不同的 Pigsty 部署之间的 CA 是不相互信任的。

本地 CA 由两个文件组成，默认放置于 files/pki/ca 目录中：

ca.crt：自签名的 CA 根证书，应当分发安装至到所有纳管节点，用于证书验证。
ca.key：CA 私钥，用于签发证书，验证 CA 身份，应当妥善保管，避免泄漏！

请保护好CA私钥文件

请妥善保管 CA 私钥文件，不要遗失，不要泄漏。我们建议您在完成 Pigsty 安装后，加密备份此文件。

使用现有CA

如果您本身已经有 CA 公私钥基础设施，Pigsty 也可以配置为使用现有 CA 。

将您的 CA 公钥与私钥文件放置于 files/pki/ca 目录中即可。

files/pki/ca/ca.key     # 核心的 CA 私钥文件，必须存在，如果不存在，默认会重新随机生成一个
files/pki/ca/ca.crt     # 如果没有证书文件，Pigsty会自动重新从 CA 私钥生成新的根证书文件

当 Pigsty 执行 install.yml 与 infra.yml 剧本进行安装时，如果发现 files/pki/ca 目录中的 ca.key 私钥文件存在，则会使用已有的 CA 。ca.crt 文件可以从 ca.key 私钥文件生成，所以如果没有证书文件，Pigsty 会自动重新从 CA 私钥生成新的根证书文件。

使用现有CA时请注意

您可以将 ca_method 参数配置为 copy，确保 Pigsty 找不到本地 CA 时报错中止，而不是自行重新生成新的自签名 CA。

信任CA

在 Pigsty 安装过程中，ca.crt 会在 node.yml 剧本的 node_ca 任务中，被分发至所有节点上的 /etc/pki/ca.crt 路径下。

EL系操作系统与 Debian系操作系统默认信任的 CA 根证书路径不同，因此分发的路径与更新的方式也不同。

rm -rf /etc/pki/ca-trust/source/anchors/ca.crt
ln -s /etc/pki/ca.crt /etc/pki/ca-trust/source/anchors/ca.crt
/bin/update-ca-trust

rm -rf /usr/local/share/ca-certificates/ca.crt
ln -s /etc/pki/ca.crt /usr/local/share/ca-certificates/ca.crt
/usr/sbin/update-ca-certificates

Pigsty 默认会为基础设施节点上的 Web 系统使用的域名签发 HTTPS 证书，您可以 HTTPS 访问 Pigsty 的 Web 系统。如果您希望在客户端电脑上浏览器访问时不要弹出“不受信任的 CA 证书”信息，可以将 ca.crt 分发至客户端电脑的信任证书目录中。

您可以双击 ca.crt 文件将其加入系统钥匙串，例如在 MacOS 系统中，需要打开“钥匙串访问” 搜索 pigsty-ca 然后“信任”此根证书

查看证书内容

使用以下命令，可以查阅 Pigsty CA 证书的内容

openssl x509 -text -in /etc/pki/ca.crt

本地 CA 根证书内容样例

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:29:e3:60:96:93:f4:85:14:fe:44:81:73:b5:e1:09:2a:a8:5c:0a
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=pigsty, OU=ca, CN=pigsty-ca
        Validity
            Not Before: Feb  7 00:56:27 2023 GMT
            Not After : Jan 14 00:56:27 2123 GMT
        Subject: O=pigsty, OU=ca, CN=pigsty-ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:c1:41:74:4f:28:c3:3c:2b:13:a2:37:05:87:31:
                    ....
                    e6:bd:69:a5:5b:e3:b4:c0:65:09:6e:84:14:e9:eb:
                    90:f7:61
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:pigsty-ca
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1
            X509v3 Subject Key Identifier: 
                C5:F6:23:CE:BA:F3:96:F6:4B:48:A5:B1:CD:D4:FA:2B:BD:6F:A6:9C
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        89:9d:21:35:59:6b:2c:9b:c7:6d:26:5b:a9:49:80:93:81:18:
        ....
        9e:dd:87:88:0d:c4:29:9e
-----BEGIN CERTIFICATE-----
...
cXyWAYcvfPae3YeIDcQpng==
-----END CERTIFICATE-----

签发证书

如果您希望通过客户端证书认证，那么可以使用本地 CA 与 cert.yml 剧本手工签发PostgreSQL 客户端证书。

将证书的 CN 字段设置为数据库用户名即可：

./cert.yml -e cn=dbuser_dba
./cert.yml -e cn=dbuser_monitor

签发的证书会默认生成在 files/pki/misc/<cn>.{key,crt} 路径下。

2 - 访问控制

Pigsty 提供了标准的安全实践：密码与证书认证，开箱即用的权限模型，SSL加密网络流量，加密远程冷备份等。

Pigsty 提供了一套开箱即用的，基于角色系统和权限系统的访问控制模型。

权限控制很重要，但很多用户做不好。因此 Pigsty 提供了一套开箱即用的精简访问控制模型，为您的集群安全性提供一个兜底。

角色系统

Pigsty 默认的角色系统包含四个默认角色和四个默认用户：

角色名称	属性	所属	描述
`dbrole_readonly`	`NOLOGIN`		角色：全局只读访问
`dbrole_readwrite`	`NOLOGIN`	dbrole_readonly	角色：全局读写访问
`dbrole_admin`	`NOLOGIN`	pg_monitor,dbrole_readwrite	角色：管理员/对象创建
`dbrole_offline`	`NOLOGIN`		角色：受限的只读访问
`postgres`	`SUPERUSER`		系统超级用户
`replicator`	`REPLICATION`	pg_monitor,dbrole_readonly	系统复制用户
`dbuser_dba`	`SUPERUSER`	dbrole_admin	pgsql 管理用户
`dbuser_monitor`		pg_monitor	pgsql 监控用户

这些角色与用户的详细定义如下所示：

pg_default_roles:                 # 全局默认的角色与系统用户
  - { name: dbrole_readonly  ,login: false ,comment: role for global read-only access     }
  - { name: dbrole_offline   ,login: false ,comment: role for restricted read-only access }
  - { name: dbrole_readwrite ,login: false ,roles: [dbrole_readonly] ,comment: role for global read-write access }
  - { name: dbrole_admin     ,login: false ,roles: [pg_monitor, dbrole_readwrite] ,comment: role for object creation }
  - { name: postgres     ,superuser: true  ,comment: system superuser }
  - { name: replicator ,replication: true  ,roles: [pg_monitor, dbrole_readonly] ,comment: system replicator }
  - { name: dbuser_dba   ,superuser: true  ,roles: [dbrole_admin]  ,pgbouncer: true ,pool_mode: session, pool_connlimit: 16 ,comment: pgsql admin user }
  - { name: dbuser_monitor ,roles: [pg_monitor] ,pgbouncer: true ,parameters: {log_min_duration_statement: 1000 } ,pool_mode: session ,pool_connlimit: 8 ,comment: pgsql monitor user }

默认角色

Pigsty 中有四个默认角色：

业务只读 (dbrole_readonly): 用于全局只读访问的角色。如果别的业务想要此库只读访问权限，可以使用此角色。
业务读写 (dbrole_readwrite): 用于全局读写访问的角色，主属业务使用的生产账号应当具有数据库读写权限
业务管理员 (dbrole_admin): 拥有DDL权限的角色，通常用于业务管理员，或者需要在应用中建表的场景（比如各种业务软件）
离线只读访问 (dbrole_offline): 受限的只读访问角色（只能访问 offline 实例，通常是个人用户，ETL工具账号）

默认角色在 pg_default_roles 中定义，除非您确实知道自己在干什么，建议不要更改默认角色的名称。

- { name: dbrole_readonly  , login: false , comment: role for global read-only access  }                            # 生产环境的只读角色
- { name: dbrole_offline ,   login: false , comment: role for restricted read-only access (offline instance) }      # 受限的只读角色
- { name: dbrole_readwrite , login: false , roles: [dbrole_readonly], comment: role for global read-write access }  # 生产环境的读写角色
- { name: dbrole_admin , login: false , roles: [pg_monitor, dbrole_readwrite] , comment: role for object creation } # 生产环境的 DDL 更改角色

默认用户

Pigsty 也有四个默认用户（系统用户）：

超级用户 (postgres)，集群的所有者和创建者，与操作系统 dbsu 名称相同。
复制用户 (replicator)，用于主-从复制的系统用户。
监控用户 (dbuser_monitor)，用于监控数据库和连接池指标的用户。
管理用户 (dbuser_dba)，执行日常操作和数据库更改的管理员用户。

这4个默认用户的用户名/密码通过4对专用参数进行定义，并在很多地方引用：

pg_dbsu：操作系统 dbsu 名称，默认为 postgres，最好不要更改它
pg_dbsu_password：dbsu 密码，默认为空字符串意味着不设置 dbsu 密码，最好不要设置。
pg_replication_username：postgres 复制用户名，默认为 replicator
pg_replication_password：postgres 复制密码，默认为 DBUser.Replicator
pg_admin_username：postgres 管理员用户名，默认为 dbuser_dba
pg_admin_password：postgres 管理员密码的明文，默认为 DBUser.DBA
pg_monitor_username：postgres 监控用户名，默认为 dbuser_monitor
pg_monitor_password：postgres 监控密码，默认为 DBUser.Monitor

在生产部署中记得更改这些密码，不要使用默认值！

pg_dbsu: postgres                             # 数据库超级用户名，这个用户名建议不要修改。
pg_dbsu_password: ''                          # 数据库超级用户密码，这个密码建议留空！禁止dbsu密码登陆。
pg_replication_username: replicator           # 系统复制用户名
pg_replication_password: DBUser.Replicator    # 系统复制密码，请务必修改此密码！
pg_monitor_username: dbuser_monitor           # 系统监控用户名
pg_monitor_password: DBUser.Monitor           # 系统监控密码，请务必修改此密码！
pg_admin_username: dbuser_dba                 # 系统管理用户名
pg_admin_password: DBUser.DBA                 # 系统管理密码，请务必修改此密码！

如果您修改默认用户的参数，在 pg_default_roles 中修改相应的角色定义即可：

- { name: postgres     ,superuser: true                                          ,comment: system superuser }
- { name: replicator ,replication: true  ,roles: [pg_monitor, dbrole_readonly]   ,comment: system replicator }
- { name: dbuser_dba   ,superuser: true  ,roles: [dbrole_admin]  ,pgbouncer: true ,pool_mode: session, pool_connlimit: 16 , comment: pgsql admin user }
- { name: dbuser_monitor   ,roles: [pg_monitor, dbrole_readonly] ,pgbouncer: true ,parameters: {log_min_duration_statement: 1000 } ,pool_mode: session ,pool_connlimit: 8 ,comment: pgsql monitor user }

权限系统

Pigsty 拥有一套开箱即用的权限模型，该模型与默认角色一起配合工作。

所有用户都可以访问所有模式。
只读用户（dbrole_readonly）可以从所有表中读取数据。（SELECT，EXECUTE）
读写用户（dbrole_readwrite）可以向所有表中写入数据并运行 DML。（INSERT，UPDATE，DELETE）。
管理员用户（dbrole_admin）可以创建对象并运行 DDL（CREATE，USAGE，TRUNCATE，REFERENCES，TRIGGER）。
离线用户（dbrole_offline）类似只读用户，但访问受到限制，只允许访问离线实例（pg_role = 'offline' 或 pg_offline_query = true）
由管理员用户创建的对象将具有正确的权限。
所有数据库上都配置了默认权限，包括模板数据库。
数据库连接权限由数据库定义管理。
默认撤销PUBLIC在数据库和public模式下的CREATE权限。

对象权限

数据库中新建对象的默认权限由参数 pg_default_privileges 所控制：

- 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 USAGE      ON SCHEMAS   TO dbrole_offline
- GRANT SELECT     ON TABLES    TO dbrole_offline
- GRANT SELECT     ON SEQUENCES TO dbrole_offline
- GRANT EXECUTE    ON FUNCTIONS TO dbrole_offline
- GRANT INSERT     ON TABLES    TO dbrole_readwrite
- GRANT UPDATE     ON TABLES    TO dbrole_readwrite
- GRANT DELETE     ON TABLES    TO dbrole_readwrite
- GRANT USAGE      ON SEQUENCES TO dbrole_readwrite
- GRANT UPDATE     ON SEQUENCES TO dbrole_readwrite
- GRANT TRUNCATE   ON TABLES    TO dbrole_admin
- GRANT REFERENCES ON TABLES    TO dbrole_admin
- GRANT TRIGGER    ON TABLES    TO dbrole_admin
- GRANT CREATE     ON SCHEMAS   TO dbrole_admin

由管理员新创建的对象，默认将会上述权限。使用 \ddp+ 可以查看这些默认权限：

类型	访问权限
函数	=X
	dbrole_readonly=X
	dbrole_offline=X
	dbrole_admin=X
模式	dbrole_readonly=U
	dbrole_offline=U
	dbrole_admin=UC
序列号	dbrole_readonly=r
	dbrole_offline=r
	dbrole_readwrite=wU
	dbrole_admin=rwU
表	dbrole_readonly=r
	dbrole_offline=r
	dbrole_readwrite=awd
	dbrole_admin=arwdDxt

默认权限

SQL 语句 ALTER DEFAULT PRIVILEGES 允许您设置将来创建的对象的权限。它不会影响已经存在对象的权限，也不会影响非管理员用户创建的对象。

在 Pigsty 中，默认权限针对三个角色进行定义：

{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE {{ pg_dbsu }} {{ priv }};
{% endfor %}

{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE {{ pg_admin_username }} {{ priv }};
{% endfor %}

-- 对于其他业务管理员而言，它们应当在执行 DDL 前执行 SET ROLE dbrole_admin，从而使用对应的默认权限配置。
{% for priv in pg_default_privileges %}
ALTER DEFAULT PRIVILEGES FOR ROLE "dbrole_admin" {{ priv }};
{% endfor %}

这些内容将会被 PG集群初始化模板 pg-init-template.sql 所使用，在集群初始化的过程中渲染并输出至 /pg/tmp/pg-init-template.sql。该命令会在 template1 与 postgres 数据库中执行，新创建的数据库会通过模板 template1 继承这些默认权限配置。

也就是说，为了维持正确的对象权限，您必须用管理员用户来执行 DDL，它们可以是：

{{ pg_dbsu }}，默认为 postgres
{{ pg_admin_username }}，默认为 dbuser_dba
授予了 dbrole_admin 角色的业务管理员用户（通过 SET ROLE 切换为 dbrole_admin 身份）。

使用 postgres 作为全局对象所有者是明智的。如果您希望以业务管理员用户身份创建对象，创建之前必须使用 SET ROLE dbrole_admin 来维护正确的权限。

当然，您也可以在数据库中通过 ALTER DEFAULT PRIVILEGE FOR ROLE <some_biz_admin> XXX 来显式对业务管理员授予默认权限。

数据库权限

在 Pigsty 中，数据库（Database）层面的权限在数据库定义中被涵盖。

数据库有三个级别的权限：CONNECT、CREATE、TEMP，以及一个特殊的’权限’：OWNERSHIP。

- name: meta         # 必选，`name` 是数据库定义中唯一的必选字段
  owner: postgres    # 可选，数据库所有者，默认为 postgres
  allowconn: true    # 可选，是否允许连接，默认为 true。显式设置 false 将完全禁止连接到此数据库
  revokeconn: false  # 可选，撤销公共连接权限。默认为 false，设置为 true 时，属主和管理员之外用户的 CONNECT 权限会被回收

如果 owner 参数存在，它作为数据库属主，替代默认的 {{ pg_dbsu }}（通常也就是postgres）
如果 revokeconn 为 false，所有用户都有数据库的 CONNECT 权限，这是默认的行为。
如果显式设置了 revokeconn 为 true：
- 数据库的 CONNECT 权限将从 PUBLIC 中撤销：普通用户无法连接上此数据库
- CONNECT 权限将被显式授予 {{ pg_replication_username }}、{{ pg_monitor_username }} 和 {{ pg_admin_username }}
- CONNECT 权限将 GRANT OPTION 被授予数据库属主，数据库属主用户可以自行授权其他用户连接权限。
revokeconn 选项可用于在同一个集群间隔离跨数据库访问，您可以为每个数据库创建不同的业务用户作为属主，并为它们设置 revokeconn 选项。

示例：数据库隔离

pg-infra:
  hosts:
    10.10.10.40: { pg_seq: 1, pg_role: primary }
    10.10.10.41: { pg_seq: 2, pg_role: replica , pg_offline_query: true }
  vars:
    pg_cluster: pg-infra
    pg_users:
      - { name: dbuser_confluence, password: mc2iohos , pgbouncer: true, roles: [ dbrole_admin ] }
      - { name: dbuser_gitlab, password: sdf23g22sfdd , pgbouncer: true, roles: [ dbrole_readwrite ] }
      - { name: dbuser_jira, password: sdpijfsfdsfdfs , pgbouncer: true, roles: [ dbrole_admin ] }
    pg_databases:
      - { name: confluence , revokeconn: true, owner: dbuser_confluence , connlimit: 100 }
      - { name: gitlab , revokeconn: true, owner: dbuser_gitlab, connlimit: 100 }
      - { name: jira , revokeconn: true, owner: dbuser_jira , connlimit: 100 }

CREATE权限

出于安全考虑，Pigsty 默认从 PUBLIC 撤销数据库上的 CREATE 权限，从 PostgreSQL 15 开始这也是默认行为。

数据库属主总是可以根据实际需要，来自行调整 CREATE 权限。