概览
此参考架构定义了在 Google Distributed Cloud (GDC) 网闸隔离配置上将 Keyfactor EJBCA Enterprise 集成为第三方证书授权机构 (CA) 的概念设计。
Keyfactor EJBCA Enterprise 是一个高度可伸缩、强大且符合 FIPS 标准的证书授权机构平台，可让组织跨异构环境管理公钥基础架构 (PKI)。
GDC 网闸隔离配置包含原生证书授权机构服务，用于在托管云边界内自动管理密钥和证书。原生 CA 服务是大多数客户的推荐解决方案，可在平台内提供全代管式无缝 PKI 功能。不过，如果组织已针对 GDC 之外的现有工作负载在 Keyfactor EJBCA 上标准化其 PKI 基础设施，则可能更愿意为在其 GDC 环境中运行的工作负载利用相同的一致 CA 架构和管理政策。
特性和功能
该解决方案为证书生命周期管理提供了几个核心功能组件：
- 自动化证书生命周期管理：利用 GDC 标准集群内的自定义 EJBCA 颁发者，通过 cert-manager 自动执行服务器证书的预配、续订和撤消。
- 标准化 ACME 自动化：支持使用 DNS-01 质询的自动证书管理环境 (ACME) 协议，使平台服务能够无缝请求和续订证书。
- 安全 HSM 集成：直接在通过 CC EAL4+ 认证的硬件安全模块 (HSM) 中对所有 CA 私钥进行加密保护，确保密钥材料绝不会离开物理安全边界。Keyfactor EJBCA Enterprise 可以使用自己的代管式 HSM，也可以连接到外部 HSM。
- 经过网闸隔离的兼容性：专用工作流，用于将 EJBCA cert-manager 颁发者映像从公共注册表镜像到 GDC 私有 Harbor 注册表，确保离线可用性。
- 出站流量隔离：使用 GDC 子网和 CloudNATGateway 资源进行出站网络配置，以将 GDC API 流量直接限制为外部 EJBCA 服务器 IP 地址。
架构原则
- 责任共担模型：客户负责运营外部 EJBCA 服务器和 HSM，拥有物理 PKI 基础设施和 CA 根密钥，而 GDC 则在标准集群内提供计算、内部 DNS 和自动化客户端层。
- 注重安全的设计：通过利用本地容器映像镜像并强制执行严格的出站流量控制，遵守经过网闸隔离的安全要求，从而最大限度地减少网络攻击面。
- 协议标准化：优先使用标准协议（ACME 和 mTLS REST）进行 CA 交互，避免专有 API 依赖项，并允许灵活的客户端集成。
架构
该架构遵循外部证书授权机构模型，其中 EJBCA 服务器及其支持的硬件安全模块 (HSM) 托管在物理 GDC 边界之外，但可通过网络访问。EJBCA 服务器可以作为硬件或软件设备部署在外部。本指南中介绍的核心集成仅要求可通过稳定的 IP 地址访问外部 EJBCA 服务器。
此架构的关键组件包括：
- EJBCA Enterprise Server：作为 Keyfactor 硬件设备或软件设备部署在外部，用于托管 CA（根 CA 和从属 CA），并在通过 CC EAL4+ 认证的 HSM 中生成所有 CA 密钥材料。
- 默认 VPC：部署用户工作负载的 VPC，这些工作负载可以位于标准 Kubernetes 集群中，也可以位于虚拟机中。
- GDC 内部 DNS：管理用于解析 ACME DNS-01 质询的本地专用 DNS 区域（使用环境变量中配置的专用域名）。
- GDC 出站流量 NAT 网关：将出站流量从集群 Pod 定向到外部 EJBCA 服务器 IP 地址。
- Harbor 私有注册表：托管镜像容器映像（例如 EJBCA cert-manager 颁发者），用于经过网闸隔离的部署。
概念和技术
本部分详细介绍了功能组件、其职责以及它们在系统中的通信方式。
基础架构和平台
- GDC 标准集群：EJBCA 签发者和 cert-manager Pod 所在的主要计算环境，用于为工作负载执行证书自动化。
- Harbor Registry：GDC 中所有容器映像的安全本地可靠来源。它提供自动扫描功能，可确保映像在部署前没有已知漏洞。
- GDC 出站网关：平台原生网络资源（子网和 CloudNATGateway），用于管理和保护从集群 Pod 到外部 CA 服务器的出站 API 流量。
服务和逻辑
- EJBCA Enterprise Server：外部 CA 引擎（软件或硬件设备），负责管理 CA 层次结构（根和下级）、验证证书请求、对证书进行签名以及记录审核记录。
- 硬件安全模块 (HSM)：符合 CC EAL4+ 标准的加密模块，负责处理密钥生成和证书签名，确保 CA 私钥绝不泄露。
- GDC 内部 DNS：管理 ACME 验证服务使用的专用 DNS 区域（
ManagedDNSZone和ResourceRecordSet），以通过临时 TXT 记录验证域名所有权。 - 具有 EJBCA 颁发者的 cert-manager：Kubernetes 原生证书控制器，可拦截证书请求并利用 EJBCA 颁发者将其转换为安全的 EJBCA API 调用。
数据流和接口
- ACME 协议：标准 API 接口，用于通过 DNS-01 质询自动颁发经过网域验证的服务器证书。
- EJBCA REST API：用于管理引导和程序化操作（例如 CSR 签名和撤消）的 RESTful 接口。
- mTLS 客户端身份验证：cert-manager 集成的主要身份验证机制，通过使用专用客户端证书的双向 TLS 验证客户端身份。
注意事项
- 可伸缩性和性能：
- 必须对外部 EJBCA 服务器进行扩缩（CPU、内存、HSM 容量），以处理并发验证和签名请求，尤其是在突发签发配置文件期间。
- GDC 出站网关资源必须具有适当的大小，以确保与外部 CA 服务器之间的延迟时间最短，从而防止在 cert-manager 验证周期内发生超时。
- 安全与合规性：
- 将 CA 根密钥隔离在外部 HSM 中可满足高安全性和合规性标准（例如 BSI VS-NfD）。
- 应使用基于角色的访问权限控制 (RBAC) 严格限制对 EJBCA 的管理员访问权限，并将其映射到唯一的客户端证书序列号。
- 可用性和可靠性：
- 建议跨多个可用区（使用主动-被动或集群配置）对外部 EJBCA 服务器进行高可用性部署，以确保持续运行并避免单点故障。
- 在 GDC 中部署多个 cert-manager 控制器副本可确保集群端自动证书颁发保持弹性。
- 运营管理：
- 客户保留 EJBCA 服务器的所有权，包括系统修补、HSM 密钥轮替和 CRL 发布。
- 客户的 GDC 平台管理员负责维护集群内 cert-manager 和 EJBCA 颁发者控制器，并管理 GDC 端专用 DNS 记录。
设计决策
此解决方案的主要架构选择侧重于在自动化与经过网闸隔离的环境的限制之间取得平衡。
EJBCA 集成选项
GDC 的原生 Certificate Authority Service 是大多数客户推荐的 PKI 解决方案，可在 GDC 网闸隔离配置环境中提供全代管式、无缝的 PKI 功能。不过，对于已在 Keyfactor EJBCA 上针对 GDC 之外的工作负载将其 PKI 基础架构标准化的组织，可以选择接受集成其现有的外部 CA 服务器。这样，他们就可以重复使用已建立的 PKI 模板、安全政策和运营模式，而无需重新设计其信任层次结构或迁移核心工作流。
ACME 验证选项
HTTP-01 和 DNS-01 ACME 质询验证协议均受完全支持。虽然本架构指南重点介绍了使用 GDC 内部 DNS 的 DNS-01 验证（非常适合无法支持入站公共 HTTP 流量的隔离私有环境），但客户可以根据其特定的网络拓扑、安全政策和工作负载要求选择任一验证方法。
mTLS 管理渠道建议
建议将双向 TLS (mTLS) 用作 cert-manager 和集成客户端的可靠身份验证方法。mTLS 利用客户端证书提供高度安全的加密客户端身份验证，但客户也可以根据其企业安全政策选择配置其 EJBCA 实例支持的其他身份验证机制。
假设和限制
前提
- 外部 EJBCA 服务器已部署、配置，并且可通过稳定的 IP 地址访问。
- EJBCA 服务器已预先配置必要的根 CA 和下级 CA，以及适当的最终实体配置文件。
- 可以使用安全机制（例如堡垒节点或离线传输工作流）将 EJBCA 颁发者容器映像发布到 GDC Harbor 注册表。
- GDC 内的标准 Kubernetes 集群已预安装或配置了 cert-manager 以供运行。
限制
- 外部 HSM 和 EJBCA 维护：GDC 控制平面不管理外部 EJBCA 服务器或其后备 HSM；生命周期操作（备份、升级、密钥轮替）由客户的 PKI 运营团队处理。
- DNSSEC 验证限制：由于使用的是专用内部 DNS，因此必须在 ACME 配置中停用服务器端 DNSSEC 验证，以避免本地专用网域出现解析失败。
- 出站流量连接依赖项：自动证书颁发服务依赖于 GDC 机架与外部 EJBCA 服务器之间的网络链路的可用性和延迟时间。