使用KMS密钥别名访问S3加密桶时s3:GetObject操作失败问题咨询

核心差异在于AWS KMS的kms:RequestAlias条件键的生效逻辑，以及S3在上传/下载加密对象时调用KMS接口的参数差异：

• 执行s3:PutObject操作时，无论你是在请求中主动指定KMS别名作为加密密钥，还是存储桶默认加密配置绑定了alias/infra_s3_key，S3调用KMS的GenerateDataKey接口时，都会将别名作为请求参数传递给KMS，此时kms:RequestAlias条件可以正常匹配，权限校验通过，所以上传操作正常。
• 执行s3:GetObject操作时，S3不需要用户指定加密密钥，会直接从对象的元数据中读取加密使用的KMS密钥的真实ARN，调用KMS的Decrypt接口时只会传递密钥ARN，不会携带别名参数，因此KMS请求中不存在kms:RequestAlias属性，你策略中的条件匹配失败，kms:Decrypt权限被拒绝，最终返回AccessDenied错误。

你将Resource替换为KMS Key ARN后生效的原因也很简单：不管是GenerateDataKey还是Decrypt请求，最终关联的都是该真实密钥ARN，不需要依赖别名相关的条件校验，因此两个操作都能正常通过权限校验。

你可以选择以下任意一种方案调整权限策略：

• 方案1：将KMS权限的条件键替换为kms:ResourceAliases，该条件键会匹配KMS密钥实际绑定的别名，无论请求使用的是ARN还是别名都能正常识别，示例配置如下：

{
    "Sid": "AllowS3KMS",
    "Effect": "Allow",
    "Action": [
        "kms:GenerateDataKey*",
        "kms:Decrypt"
    ],
    "Resource": "*",
    "Condition": {
        "StringLike": {
            "kms:ResourceAliases": "alias/infra_s3_key"
        }
    }
}

• 方案2：直接保留你当前的修改，在Resource字段填写KMS Key的真实ARN，不需要额外加别名相关的条件，配置更稳定，不会受别名绑定关系变更影响。

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