Cert-manager 中使用 Vault Kubernetes 认证的权限问题解析

问题背景

在使用 cert-manager 与 HashiCorp Vault 集成时，许多用户会遇到 Kubernetes 认证方式下的权限问题。具体表现为当配置 ClusterIssuer 使用 Kubernetes 认证时，cert-manager 无法为指定的服务账户创建令牌，导致 Vault 认证失败。

错误现象

典型的错误信息如下：

Error initializing issuer: while requesting a Vault token using the Kubernetes auth: while requesting a token for the service account /vault-test-cert-manager-sa: serviceaccounts "vault-test-cert-manager-sa" is forbidden: User "system:serviceaccount:cert-manager:cert-manager" cannot create resource "serviceaccounts/token" in API group "" in the namespace "cert-manager"

根本原因分析

这个问题的核心在于 Kubernetes 的 RBAC 权限配置。cert-manager 需要能够为指定的服务账户创建令牌，但默认情况下它没有这个权限。具体来说：

1. cert-manager 控制器运行在 cert-manager 命名空间下，使用 cert-manager 服务账户
2. 当配置 ClusterIssuer 使用 serviceAccountRef 时，cert-manager 需要为该服务账户创建令牌
3. 创建 serviceaccounts/token 需要显式的 RBAC 授权

解决方案

正确的 RBAC 配置

以下是正确的权限配置示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vault-sa-token-creator
  namespace: cert-manager  # 必须与目标服务账户同命名空间
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  resourceNames: ["vault-test-cert-manager-sa"]  # 目标服务账户名称
  verbs: ["create"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cert-manager-vault-sa-token-creator
  namespace: cert-manager
subjects:
- kind: ServiceAccount
  name: cert-manager  # cert-manager 的服务账户
  namespace: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: vault-sa-token-creator

关键配置要点

1. 命名空间匹配：Role 和 RoleBinding 必须与目标服务账户位于同一命名空间
2. 资源名称指定：resourceNames 必须准确指定要创建令牌的服务账户名称
3. 主体正确：RoleBinding 的主体必须是 cert-manager 的服务账户，而不是目标服务账户

常见误区

1. 错误的资源名称：很多用户会错误地将 resourceNames 设置为 ClusterIssuer 的名称，而不是服务账户名称
2. 错误的命名空间：权限配置放在了错误的命名空间
3. 错误的主体：将 RoleBinding 的主体设置为目标服务账户，而不是 cert-manager 的服务账户

最佳实践建议

1. 为每个 Vault 认证单独创建专用的服务账户
2. 使用明确的命名约定，避免混淆
3. 在生产环境中，考虑使用更细粒度的权限控制
4. 定期审计和验证 RBAC 配置

通过正确理解 Kubernetes 的 RBAC 模型和 cert-manager 的工作机制，可以有效地解决这类权限问题，实现 cert-manager 与 Vault 的安全集成。