如何在Anthos集群中使用GCP Secret Manager？跨GKE/EKS安全调用密钥方案

核心通过GCP Secret Manager CSI驱动结合工作负载身份实现安全访问，操作步骤如下：

• 启用集群组件：针对Anthos GKE集群，执行命令启用CSI驱动：

  gcloud container clusters update CLUSTER_NAME --update-addons=SecretManagerCsiDriver=ENABLED
  

  替换CLUSTER_NAME为你的集群名称。
• 配置工作负载身份：
  1. 在K8s集群中创建服务账号，例如sm-access-sa；
  2. 创建对应GCP服务账号，为其绑定roles/secretmanager.secretAccessor角色，限制仅能访问指定Secret Manager密钥；
  3. 将K8s服务账号与GCP服务账号绑定，完成身份映射。
• 创建SecretProviderClass：定义CSI驱动的密钥访问规则，示例YAML：

  apiVersion: secrets-store.csi.x-k8s.io/v1
  kind: SecretProviderClass
  metadata:
    name: gcp-secrets
  spec:
    provider: gcp
    parameters:
      secrets: |
        - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/latest"
          fileName: "app-secret"
  

  替换PROJECT_ID和SECRET_NAME为实际值。
• 挂载密钥到应用Pod：在Pod配置中引用上述SecretProviderClass，将密钥挂载到容器内指定路径：

  volumes:
    - name: secret-store
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "gcp-secrets"
  containers:
    - name: your-app
      volumeMounts:
        - name: secret-store
          mountPath: "/mnt/secrets"
          readOnly: true
  

基于统一的身份认证+CSI驱动模式，针对两类集群的环境差异适配：

GKE Anthos集群实现 #

复用问题1的方案，强化安全边界：

• 最小权限原则：给GCP服务账号仅授予单个/指定组密钥的读取权限，避免全局Secret Manager访问；
• 命名空间隔离：不同应用的K8s服务账号绑定独立的GCP服务账号，防止权限交叉。

EKS Anthos集群实现 #

借助Anthos身份服务完成跨云身份验证，步骤如下：

• 启用Anthos身份服务：确保EKS集群已注册到Anthos管理控制台，并安装Anthos身份服务组件；
• 配置GCP身份权限：创建具备roles/secretmanager.secretAccessor权限的GCP服务账号，限制密钥访问范围；
• 映射跨云身份：将EKS中的K8s服务账号映射到上述GCP服务账号，通过Anthos身份服务完成身份验证，无需暴露GCP密钥；
• 部署CSI驱动与配置：在EKS集群中安装GCP Secret Manager CSI驱动，创建与GKE一致的SecretProviderClass，在Pod中挂载密钥卷。

通用安全最佳实践 #

• 密钥版本管理：定期轮换Secret Manager中的密钥版本，应用通过latest版本自动获取最新密钥，无需重启Pod；
• 审计监控：开启Secret Manager审计日志，结合Anthos监控跟踪密钥访问行为，及时发现异常；
• 避免硬编码：所有应用必须通过CSI卷或K8s Secret注入环境变量获取密钥，禁止代码硬编码。

内容的提问来源于stack exchange，提问作者Aadesh kale