请求为开发者配置所属项目专属KMS密钥的细粒度访问权限

当然可行！这正是KMS细粒度IAM权限设计要解决的核心场景，完全可以实现开发者仅操作所属项目的专属密钥，避免权限扩散到全员的问题。下面是具体的落地方案：

1. 为每个项目创建独立的KMS客户主密钥（CMK） #

首先给每个项目单独创建专属的KMS CMK，而不是共享一个密钥。每个密钥的资源ARN是唯一的，这是实现隔离的基础。比如：

• 项目A的KMS密钥ARN：arn:aws:kms:us-east-1:123456789012:key/abc123-xxx-xxx-xxx-xxxx
• 项目B的KMS密钥ARN：arn:aws:kms:us-east-1:123456789012:key/def456-xxx-xxx-xxx-xxxx

2. 配置细粒度的IAM权限策略 #

针对每个项目的开发者（或项目专属IAM组），绑定仅允许操作对应项目KMS密钥的权限策略，拒绝访问其他密钥。示例策略如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/abc123-xxx-xxx-xxx-xxxx"
    },
    {
      "Effect": "Deny",
      "Action": "kms:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "kms:ResourceArn": "arn:aws:kms:us-east-1:123456789012:key/abc123-xxx-xxx-xxx-xxxx"
        }
      }
    }
  ]
}

• 允许的操作是Mozilla sops加密/解密所需的核心动作，可根据实际需求调整。
• 通过Deny语句兜底，确保开发者无法访问任何非所属项目的KMS密钥。

3. 用IAM组管理项目权限 #

为每个项目创建专属的IAM组，把该项目的开发者加入对应组，再把上面的细粒度策略绑定到组上：

• 项目A的IAM组：proj-a-devs，绑定项目A的KMS权限策略
• 项目B的IAM组：proj-b-devs，绑定项目B的KMS权限策略

这样即使需要临时授权第三人，只需把该用户加到对应项目的IAM组即可，权限仅局限于该项目的密钥，不会扩散到其他项目。

4. 配合sops配置锁定密钥 #

在每个项目的sops.yaml配置文件中，指定该项目专属的KMS密钥ARN，示例：

creation_rules:
  - kms: arn:aws:kms:us-east-1:123456789012:key/abc123-xxx-xxx-xxx-xxxx

这样开发者用sops操作时，默认只会调用所属项目的密钥，即使手动指定其他密钥，也会被IAM权限拦截。

额外安全建议 #

• 不要授予任何开发者kms:ListKeys权限，这样他们在KMS门户中看不到其他项目的密钥，从根源减少越权风险。
• 定期通过IAM Access Analyzer审计权限，确保没有意外添加的全局KMS权限。
• 临时授权时使用IAM临时角色，并设置合理的过期时间，避免权限长期留存。

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