cert-manager 使用 Vault Issuer 时的 Kubernetes 服务账户权限问题解析

在 Kubernetes 集群中使用 cert-manager 与 Vault 集成时，通过 Kubernetes 服务账户进行认证是一种常见做法。然而，许多用户在配置过程中会遇到一个特定的权限问题，导致无法成功签发证书。

当 cert-manager 尝试使用 Vault 的 Kubernetes 认证方式时，它需要能够为目标命名空间中的服务账户创建投影令牌。默认情况下，cert-manager 的 Helm 安装并不会自动授予这些权限，这是出于安全考虑的有意设计。

问题的核心在于 cert-manager 服务账户缺少创建服务账户令牌的权限。当配置指向其他命名空间的服务账户时，会出现类似以下的错误提示："无法在命名空间中为服务账户创建令牌资源"。

要解决这个问题，需要手动创建适当的 RBAC 权限。具体来说，需要在目标命名空间中创建一个 Role 和 RoleBinding：

1. 创建一个 Role，授予创建服务账户令牌的权限
2. 创建一个 RoleBinding，将上述 Role 绑定到 cert-manager 的服务账户

这种设计选择体现了 Kubernetes 安全模型中的最小权限原则。cert-manager 团队有意不默认授予跨命名空间的广泛权限，因为这可能会带来安全风险。相反，他们要求用户显式地为每个需要访问的服务账户配置权限。

对于生产环境中的部署，建议遵循以下最佳实践：

1. 严格限制 cert-manager 可以访问的服务账户范围
2. 为每个需要使用的服务账户单独配置权限
3. 定期审计这些权限配置
4. 考虑使用命名空间隔离来进一步限制权限范围

理解这一权限模型对于安全地使用 cert-manager 与 Vault 集成至关重要。虽然需要额外的手动配置步骤，但这种设计提供了更精细的权限控制和更高的安全性。