Cert-Manager 与 Vault 集成中的 JWT 受众（aud）问题解析与解决方案

在 Kubernetes 生态中，Cert-Manager 作为证书管理的核心组件，常与 HashiCorp Vault 集成以实现安全的证书签发。然而，当通过 Kubernetes 服务账户（ServiceAccount）进行 Vault 认证时，JWT 令牌的受众（audience，简称 aud）字段的严格校验可能导致集成失败。本文将深入分析该问题的技术背景，并探讨优雅的解决方案。

---

问题背景：aud 校验的冲突机制

当 Cert-Manager 通过 Vault 的 Kubernetes 认证后端获取令牌时，涉及两个关键校验层：

1. Cert-Manager 的强制 aud 限制
   出于安全考虑，Cert-Manager 默认在创建服务账户令牌时强制指定 aud 为 vault。这种设计旨在防止令牌被滥用于其他系统。

2. Vault 的默认 aud 校验
   Vault 的 Kubernetes 认证后端默认期望令牌的 aud 包含 Kubernetes API 服务器的主机地址（如 AKS/EKS 的公共端点）。若角色创建时未显式配置 aud，Vault 会隐式校验此值。

这种双向校验的冲突导致认证失败，表现为错误 "token audiences ["vault"] is invalid for this cluster。

---

技术影响分析

该限制对实际部署的影响主要体现在：

• 混合云场景：当 Vault 部署在集群外部时（如独立基础设施），Kubernetes 原生服务账户认证流程与 Cert-Manager 的强制策略不兼容。
• 策略统一性：其他服务（如外部应用）可能已采用标准 Kubernetes 主机名作为 aud 与 Vault 集成，而 Cert-Manager 成为唯一需要特殊处理的组件。
• 自动化复杂度：现有方案需为 Cert-Manager 单独配置 JWT 认证后端，增加了运维复杂度。

---

解决方案：动态 aud 配置能力

核心设计思路

通过在 Cert-Manager 的 Vault Issuer 配置中引入 additionalAudiences 字段，允许用户扩展默认的 aud 列表。例如：

spec:
  vault:
    auth:
      kubernetes:
        serviceAccountRef: 
          name: vault-auth
        additionalAudiences:
        - "https://my-aks-cluster.hcp.eastus.azmk8s.io"

安全权衡评估

1. 风险可控性

   • 攻击者仍需具备目标命名空间的高权限才能利用令牌
   • Vault 策略（policy）仍作为最终访问控制层
   • 符合最小权限原则，因为 aud 扩展需显式声明

2. 默认安全保留
   保留 vault 作为默认 aud，确保向后兼容性，同时允许关键场景下的灵活配置。

---

实施建议

对于生产环境，建议采用分阶段部署：

1. 测试阶段

   • 在 Vault 角色中明确配置 bound_audiences 包含 Cert-Manager 的 aud
   • 通过 Vault 审计日志监控令牌使用情况

2. 策略强化

   path "pki/issue/*" {
     capabilities = ["create", "update"]
     required_parameters = ["common_name"]
     allowed_parameters = {
       "common_name" = ["*.example.com"]
     }
   }
   

3. 版本适配
   该功能需 Cert-Manager 1.13+ 版本支持，升级时需验证 CRD 变更的兼容性。

---

架构启示

这一改进体现了云原生工具链的渐进式安全理念：

• 默认安全：保持开箱即用的安全基线
• 可控灵活：通过显式配置满足边缘场景
• 生态协同：尊重上下游组件的约定俗成

未来类似集成可参考此模式，在安全与可用性之间寻求动态平衡。