安全公告

选择文档版本：

如需评估 AlloyDB Omni Kubernetes 部署的安全状况并规划控制平面和数据库集群升级，请查看本页面上的安全政策、操作器架构、基于角色的访问权限控制 (RBAC) 和安全上下文，以及常见漏洞和风险 (CVE) 披露做法。

如需在 Feed 阅读器中接收最新的 AlloyDB Omni 版本说明和安全更新，请订阅 AlloyDB Omni 版本说明 Feed。

Operator 架构和安全上下文

AlloyDB Omni on Kubernetes 将 Kubernetes 控制平面与处理应用查询的数据库引擎 Pod 分离开来：

  • 控制平面和操作器组件：每个 AlloyDB Omni 操作器版本都包含 10 个基于 Red Hat 通用基础映像 9 (UBI 9) 构建的容器映像：
    • operator/fleet-operator：舰队级 Kubernetes 控制器，用于协调 DBCluster 和舰队自定义资源
    • operator/local-operator：实例级 Kubernetes 控制器，用于管理本地数据库 Pod 生命周期，并且仅与受信任的集群内部 Kubernetes API 服务器通信
    • alloydbomni-operator-catalog 和 alloydbomni-operator-olm-bundle：Red Hat OpenShift Operator Lifecycle Manager (OLM) 目录索引和声明式软件包元数据映像
    • operator/dbinit 和 operator/backupinit：用于数据库引导、备份和恢复工作流的临时初始化容器
    • operator/alloydbomni-monitor（取代 monitoring-agent）、operator/g-pgbouncer、operator/logrotate 和 operator/node-manager：用于健康状况探测、连接池、日志轮替和存储管理的配套边车和节点管理容器
  • RBAC 和安全上下文：AlloyDB Omni 操作器使用限定范围的 Kubernetes Role 和 ClusterRole 权限来协调目标命名空间内的自定义资源，并在受限容器安全上下文中运行控制平面和边车工作负载。
  • 数据库引擎 Pod：由操作器管理的数据库实例运行独立的 AlloyDB Omni 数据库内核容器映像。如需验证您的操作器版本支持哪些数据库内核版本，请参阅选择兼容的 Kubernetes 操作器和数据库集群版本。

范围和严重程度过滤

为了将修复工作流集中在可操作的安全通告上并减少扫描器噪声，AlloyDB Omni 漏洞摘要和详细 CVE 日志遵循以下报告政策：

  • 严格的“严重”和“高”严重级别过滤：漏洞摘要表和详细 CVE 日志仅报告根据美国国家漏洞数据库 (NVD) 和上游供应商严重级别评级评为“严重”和“高”严重级别的 CVE。摘要计数和详细日志中不包含低严重级别和中严重级别的通告。
  • 解耦的控制平面和数据库内核报告：AlloyDB Omni on Kubernetes 下的控制平面公告会报告 10 个 AlloyDB Omni 操作器和边车容器映像特有的漏洞。
  • 按版本隔离：详细的 CVE 日志会使用标准化的 4 列架构（CVE ID、Severity、Impacted images 和 Mitigated in）整理到每个发布版本的专用子页面中。在每个发布日志中， 在后续版本中修复的漏洞会在 Mitigated in 列中显示缓解漏洞的发布版本。

漏洞评估和刷新政策

Google 会定期根据 NVD、Red Hat 安全数据、Debian 安全跟踪器和 Go 漏洞数据库扫描所有已发布的 AlloyDB Omni 容器映像。 发布新版本时，Google 会刷新 AlloyDB Omni 安全公告：

  • 已修复的 CVE：早期 AlloyDB Omni 操作器控制平面容器映像中存在的漏洞在后续操作器版本中得到了缓解。Google 会将安全补丁应用于最新支持的 AlloyDB Omni 操作器版本，以及受支持的 PostgreSQL 主要版本 18、17、16 和 15 的最新次要版本。
  • 被取代的容器映像：当新的 AlloyDB Omni 操作器版本缓解了早期版本中的 CVE 时，Google 会将被取代的容器映像摘要标记为已弃用。始终部署与最新支持的版本对应的 Operator 和控制平面代理映像。

FIPS 140-3 合规性和 CVE 补丁

为了在持续修补次要版本和补丁版本中的安全漏洞的同时，保持符合联邦信息处理标准 (FIPS) 140-3，AlloyDB Omni 将其内部经过 FIPS 验证的加密模块与其外部加密和协议库解耦：

  • 加密模块的 FIPS 验证：美国国家标准与技术研究院 (NIST) 加密模块验证计划 (CMVP) 会对冻结的内部加密模块或提供程序进行认证，并颁发证书编号。修改该经过验证的边界内的任何指令都会改变其嵌入的基于哈希的消息认证码 (HMAC) 完整性校验和，并使证书失效。
  • 部署的 FIPS 合规性：当 AlloyDB Omni 部署在启用了 FIPS 的主机操作系统（例如 Red Hat Enterprise Linux [RHEL] 9，且 /proc/sys/crypto/fips_enabled 文件设置为 1）上运行时，它会以符合 FIPS 140-3 的模式运行。在此模式下，部署会通过 FIPS 验证的模块路由所有与安全相关的加密操作，并启用开机已知答案测试 (KAT) 和 HMAC 完整性检查。它还会强制执行已获批准的 TLS 1.2 或更高版本的传输层安全协议 (TLS) 版本、已获批准的加密套件以及 scram-sha-256 密码身份验证方法。AlloyDB Omni 操作器容器映像和 Red Hat UBI 9 数据库容器映像 (-ubi9) 已支持 FIPS，贵组织负责在底层主机操作系统上启用和验证 FIPS 模式。如需了解详情，请参阅安全性和 FIPS 合规性。
  • FIPS 边界外的 CVE 修补：协议解析和网络库（例如 TLS 状态机、X.509 和 ASN.1 证书解析、HTTP/2 和网络 I/O）位于冻结的 FIPS 模块边界外的外层。由于这些组件位于经过验证的边界之外，因此 Google 会在次要版本和补丁版本中修补外层 CVE，而无需修改内部加密模块或使其 NIST CMVP 认证失效。只有低级加密基元实现本身存在漏洞时，才需要更新内部 FIPS 模块。
下表介绍了 AlloyDB Omni 操作器控制平面和边车容器映像中的加密堆栈，包括冻结的内部 FIPS 边界以及在各个版本中进行修补的外部加密和协议层：

加密堆栈 控制平面容器映像 二进制文件 内部 FIPS 验证模块或提供程序 外部加密和协议层
使用 GOFIPS140=v1.0.0 build 设置的 Go 内置 FIPS operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Go 加密模块 v1.0.0，NIST CMVP 证书 #5247 Go 标准库软件包 crypto/tls、crypto/x509 和 net/http，外部 Go 软件包（例如 golang.org/x/crypto），以及 Go 运行时和编译器
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer RHEL 9 OpenSSL FIPS 提供程序 openssl-libs RPM 软件包中的 /lib64/libssl.so.3 和 /lib64/libcrypto.so.3，以及 pgbouncer C 二进制文件
BoringSSL 和 BoringCrypto operator/alloydbomni-monitor /monitoring_agent 使用 boringcrypto 构建的 Go 二进制文件 Google BoringCrypto 模块 (BCM) 适用于 monitoring_agent 的 Go crypto/tls、crypto/x509 和 net/http 软件包

后续步骤