从GCP转用AWS后如何配置权限让团队仅可访问自有资源?
AWS仅允许用户操作自身创建资源的权限配置方案
AWS没有和GCP项目完全对等的原生概念,你可以根据需求选择两种实现方案:同账号下基于标签的IAM权限隔离(适配你当前已创建用户组的现状),或基于AWS Organizations的多账号隔离(隔离度更高,逻辑更接近GCP项目)。
方案一:同账号IAM标签权限隔离(适配当前配置)
先删除用户组原有EC2、S3全量访问权限,为用户组绑定如下拆分的自定义权限策略即可:
1. EC2权限策略
核心逻辑是强制用户创建EC2实例时必须打上creator标签,值为自身IAM用户名,后续仅允许操作标签匹配自己用户名的实例:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "允许创建EC2时打自身用户名标签", "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/creator": "${aws:username}" } } }, { "Sid": "允许操作自身创建的EC2实例", "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances", "ec2:TerminateInstances", "ec2:DescribeInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/creator": "${aws:username}" } } }, { "Sid": "允许查看创建EC2必备的公共基础资源", "Effect": "Allow", "Action": [ "ec2:DescribeKeyPairs", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeImages" ], "Resource": "*" } ] }
2. S3权限策略
核心逻辑和EC2一致,强制创建存储桶时打creator标签,仅允许操作自身创建的存储桶及桶内文件:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "允许创建带自身标签的S3存储桶", "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringEquals": { "aws:RequestTag/creator": "${aws:username}" } } }, { "Sid": "允许管理自身创建的S3存储桶及内容", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*", "arn:aws:s3:::*/*" ], "Condition": { "StringEquals": { "s3:ResourceTag/creator": "${aws:username}" } } } ] }
方案二:多账号隔离(接近GCP项目体验)
如果需要更高的资源隔离度,避免外部团队看到你账号内其他资源,可以使用AWS Organizations创建独立的成员账号,将外部团队的用户全部创建在该独立账号内,完全和你的主账号资源隔开,权限边界和GCP的项目隔离逻辑一致。
内容的提问来源于stack exchange,提问作者Nate
相关产品推荐
相关产品推荐

