获取存储桶策略中Lambda角色ARN，配置S3访问权限限制

你的场景在企业AWS环境里特别常见——没法修改全局预设角色（比如power user）的权限时，用Bucket Policy强制隔离特定存储桶的访问权限确实是最优解。下面是符合你需求的完整配置方案，以及关键细节的拆解：

完整Bucket Policy示例 #

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:role/YourLambdaExecutionRole",
                    "arn:aws:sts::123456789012:assumed-role/YourLambdaExecutionRole/YourLambdaFunctionName"
                ]
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::your-bucket-name",
                "arn:aws:s3:::your-bucket-name/*"
            ]
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::your-bucket-name",
                "arn:aws:s3:::your-bucket-name/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::123456789012:role/YourLambdaExecutionRole",
                        "arn:aws:sts::123456789012:assumed-role/YourLambdaExecutionRole/YourLambdaFunctionName"
                    ]
                }
            }
        }
    ]
}

关键细节说明 #

• 为什么要同时添加Lambda角色ARN和假定角色ARN？
  Lambda执行时会通过「假定身份」（Assumed Role）访问资源，这个身份的ARN格式是arn:aws:sts::account-id:assumed-role/role-name/function-name。只加执行角色ARN的话，可能会漏掉Lambda实际使用的身份，导致访问被拒绝。同时包含两者能确保覆盖所有Lambda访问该桶的场景。

• 权限评估逻辑
  AWS遵循「显式拒绝优先」原则，但这里我们通过Condition让拒绝语句只针对非白名单身份生效。允许语句会先匹配白名单角色，确保它们的访问正常，其他所有请求都会被拒绝——完美绕开了你无法修改的全局power user权限。

• 需要替换的占位符
  把示例里的这些内容换成你的实际信息：

  • 123456789012：你的AWS账号ID
  • YourLambdaExecutionRole：Lambda执行角色的名称
  • YourLambdaFunctionName：你的Lambda函数名称
  • your-bucket-name：目标存储桶的名称

验证建议 #

应用Policy后，记得做这两步验证：

• 测试Lambda函数对存储桶的读写操作，确认功能正常
• 用企业power user账号尝试访问存储桶（比如控制台浏览或CLI执行s3 ls），确认被拒绝

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