如何为每个GKE工作负载配置专属KMS密钥访问权限？

针对你遇到的问题——共享同一个IAM服务账号的GKE工作负载，需要实现仅能访问自身专属KMS密钥的控制，且不想为每个工作负载创建独立IAM账号，以下是可行的实现思路：

核心思路：利用工作负载身份的请求属性+IAM条件匹配 #

GKE工作负载通过工作负载身份转换为IAM身份时，请求上下文会携带Kubernetes命名空间和K8s服务账号的属性，你可以基于这些属性结合KMS密钥的命名规范，编写IAM条件来实现细粒度访问控制。

步骤1：统一KMS密钥命名规范 #

为每个工作负载对应的KMS密钥设置包含其K8s命名空间和服务账号的名称，比如：

projects/[你的项目ID]/locations/[区域]/keyRings/[密钥环名]/cryptoKeys/[命名空间]-[K8s服务账号名]

示例：projects/my-proj/locations/us-central1/keyRings/my-keyring/cryptoKeys/myns1-myuser，对应命名空间myns1下的K8s服务账号myuser。

步骤2：为共享IAM账号绑定带条件的KMS权限 #

给所有工作负载共享的IAM服务账号绑定roles/cloudkms.cryptoKeyDecrypter（或你需要的其他KMS角色），同时添加IAM条件，限制该账号仅能访问与自身工作负载属性匹配的密钥。

示例IAM策略（替换占位符为你的实际信息）：

{
  "bindings": [
    {
      "role": "roles/cloudkms.cryptoKeyDecrypter",
      "members": [
        "serviceAccount:你的共享IAM账号@你的项目ID.iam.gserviceaccount.com"
      ],
      "condition": {
        "title": "限制工作负载访问专属密钥",
        "expression": "resource.name == 'projects/你的项目ID/locations/区域/keyRings/密钥环名/cryptoKeys/' + request.auth.attribute.namespace + '-' + request.auth.attribute.service_account"
      }
    }
  ]
}

这个条件会验证：请求来源的工作负载所属命名空间+K8s服务账号，是否与KMS密钥的名称完全匹配，只有匹配时才能获取解密权限。

关键说明 #

• 工作负载身份认证后，request.auth.attribute.namespace和request.auth.attribute.service_account这两个变量会自动携带请求来源的K8s命名空间和服务账号信息，无需额外配置。
• 这种方式无需为每个工作负载创建独立IAM账号，仅通过一个共享账号+IAM条件即可实现数千个工作负载的细粒度控制。

注意事项 #

• 确保K8s服务账号+命名空间的组合全局唯一，避免密钥命名冲突导致权限混乱。
• 若需要更灵活的匹配规则（比如允许某个命名空间下的所有工作负载访问对应前缀的密钥），可以修改条件表达式，比如使用resource.name.startsWith(...)。

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