3. 容器镜像与工作负载证书需求
在容器与 Kubernetes 环境中，“证书”并不是一种单一对象。镜像签名、工作负载身份、服务网格 mTLS、准入控制 Webhook 这四类场景都会用到证书或密钥材料，但它们的签发主体、消费方、生命周期、信任根和治理边界完全不同。如果把它们混在一个 CA、一套轮换策略或一个 RBAC 权限模型里管理，最常见的结果是：轮换一次镜像签名密钥，却意外中断了服务网格的 mTLS；或者为了图省事把 Webhook 证书有效期设成三年，导致集群升级时集中失效。理解这四类证书的边界，是后续设计证书治理体系的前提。
四类证书的本质差异
先看它们各自解决什么问题。镜像签名证书用于回答“这个镜像是否由可信的构建流水线产出、是否被篡改”，它作用于制品供应链，验证发生在镜像被拉取或部署之前，典型实现是 Cosign/Sigstore 的密钥对或 Fulcio 短时证书。工作负载身份证书用于回答“这个 Pod/工作负载是谁”，它把 Kubernetes 的 ServiceAccount 身份映射为可被外部系统验证的凭证，典型实现是 SPIRE、Istio 的 SDS 或云厂商的 IRSA/Workload Identity。服务网格证书用于回答“两个工作负载之间的通信是否加密且双向可信”，它作用于数据平面，由网格控制面（如 Istiod）签发短时 mTLS 证书。准入控制 Webhook 证书用于回答“API Server 与 Webhook 之间的 TLS 通道是否可信”，它作用于控制平面，由集群管理员或 cert-manager 签发，供 ValidatingWebhookConfiguration/MutatingWebhookConfiguration 引用。
治理边界一：签发主体与信任根必须分离
四类证书最关键的边界是信任根不能共用。镜像签名证书的信任根通常来自 Sigstore 的 Fulcio CA 或企业自建的签名 CA，它的验证方是集群外的策略引擎（如 Kyverno、OPA Gatekeeper）或镜像仓库。工作负载身份证书的信任根来自 SPIRE Server 或云厂商 IAM，验证方是外部服务。服务网格证书的信任根是网格自己的 Citadel/Istiod CA，验证方是网格内的 Sidecar。Webhook 证书的信任根是集群内的 cert-manager 自签 CA 或企业 PKI，验证方是 API Server。
如果把这四者塞进同一个 CA，一旦该 CA 私钥泄露，攻击者可以伪造镜像签名、伪造工作负载身份、伪造网格内身份、伪造 Webhook 服务端证书——攻击面从单一平面扩散到全部平面。因此治理上应做到：每个平面至少一个独立中间 CA，根 CA 离线保存，中间 CA 私钥通过 HSM 或 KMS 保护，且各平面的签发权限通过独立 RBAC 隔离。
治理边界二：生命周期与轮换策略不可统一
四类证书的有效期差异极大，统一轮换策略会带来不必要的风险。镜像签名密钥通常是长期密钥（用于验证历史镜像），但 Sigstore 的 Fulcio 证书是短时的（约 10 分钟），签名时绑定 OIDC 身份。工作负载身份证书有效期通常为几分钟到几小时，由 SPIRE Agent 自动轮换。服务网格证书默认 24 小时，Istiod 在证书剩余 50% 有效期时触发轮换。Webhook 证书通常为 1 年，但轮换时必须同步更新 WebhookConfiguration 中的 caBundle 字段，否则 API Server 会因 CA 不匹配而拒绝连接。
治理边界三：失效影响范围与恢复路径不同
理解失效影响有助于设计告警和应急预案。镜像签名证书失效时，已运行的 Pod 不受影响，但新镜像无法通过准入校验，表现为 Deployment 卡在创建阶段。工作负载身份证书失效时，Pod 访问云 API 或数据库会返回 401/403，业务调用链断裂，但 Pod 本身仍在运行。服务网格证书失效时，Sidecar 之间的 mTLS 握手失败，表现为服务间调用大量 503 或 TLS handshake error，影响面最大。Webhook 证书失效时，API Server 无法与 Webhook 建立 TLS 连接，所有经过该 Webhook 的 API 请求被拒绝，可能导致集群无法创建任何资源。
因此告警策略应差异化：镜像签名证书关注“签名验证失败率”和“密钥过期时间”；工作负载身份证书关注“SVID 轮换失败次数”和“身份验证错误率”；服务网格证书关注“Citadel 签发失败率”和“mTLS 握手错误率”；Webhook 证书关注“caBundle 与证书不匹配”和“Webhook 调用超时”。
治理边界四：权限与审计的隔离
四类证书的签发权限应分配给不同的角色。镜像签名密钥由构建平台团队持有，不应授予集群管理员；工作负载身份由平台安全团队通过 SPIRE Server 管理；服务网格证书由网格运维团队通过 Istiod 管理；Webhook 证书由集群管理员通过 cert-manager 管理。审计上，每类证书的签发、轮换、吊销都应记录独立的审计日志，并关联到具体的 ServiceAccount 或工作负载身份，便于事后追溯。
| 证书类型 | 签发主体 | 典型有效期 | 轮换方式 | 失效首要表现 |
|---|---|---|---|---|
| 镜像签名证书 | 构建流水线 / Fulcio | 密钥长期，证书短时 | 随构建流程更新 | 新镜像无法部署 |
| 工作负载身份证书 | SPIRE / 云 IAM | 分钟 ~ 小时 | Agent 自动轮换 | 外部资源访问 401/403 |
| 服务网格证书 | Istiod / Citadel | 默认 24 小时 | SDS 动态下发 | 服务间 503 / TLS 错误 |
| Webhook 证书 | cert-manager / 自签 | 通常 1 年 | 手动或自动续期 + caBundle 更新 | API 请求被拒绝 |
落地建议：从边界梳理到治理清单
在实际落地时，建议先做一次“证书资产盘点”，把集群中所有证书按上述四类归位，记录每类证书的签发者、消费方、有效期、轮换方式和负责人。然后为每类证书定义独立的轮换 SOP 和告警阈值。例如，服务网格证书的告警阈值可设为“剩余有效期低于 6 小时”，Webhook 证书设为“剩余有效期低于 30 天”，工作负载身份证书设为“轮换失败连续 3 次”。最后，通过策略引擎（如 Kyverno）强制要求所有 Webhook 必须引用 cert-manager 签发的证书，禁止使用自签长期证书，从源头控制风险。