AWS 使用tag进行精细权限控制

AWS 使用tag进行精细权限控制

AWS一个账号下面可以通过IAM创建多个用户，但默认情况下，资源是没有用户属性的，一个账号下的资源，只要用户有这种资源的操作权限，那么不过是你自己创建的还是其他用户创建的，你都可以操作。

但在客户的实际使用场景中，有时需要隔离各用户之间的资源。按照AWS的建议，那你需要创建不同的账号，比如你有开发测试资源环境，还有生产资源环境，那么你需要创建两个账号，但创建两个账号，在查询费用的时候不方便，AWS提供consolidateBill的授权方案，可以合并账单。

所以AWS官方是没有一套简单的方法可以实现我们想要的效果的。

具体可以参考AWS开发者论坛很stackoverflow上的一些帖子

IAM的授权机制：

AWS是通过策略来定义权限，再将这些策略授予用户、组或者角色，使用户、组或者角色拥有相应的权限。

IAM 策略是包含一个或多个语句的JSON 文档。每个语句的结构如下：

{

"Statement":[{

"Effect":"effect",

"Action":"action",

"Resource":"arn",

"Condition":{

"condition":{

"key":"value"

}

}

}

]

}

组成语句的各个元素如下：

Effect：此 effect 可以是 Allow 或 Deny。默认情况下 IAM 用户没有使用资源和 API 操作的权限，因此，所有请求均会被拒绝。显式允许将覆盖默认规则。显式拒绝将覆盖任何允许。

Action：action 是对其授予或拒绝权限的特定 API 操作。

Resource：操作影响的资源。有些 Amazon EC2 API 操作允许您在策略中包括该操作可以创建或修改的特定资源。要在语句中指定资源，您需要使用其 Amazon 资源名称 (ARN)。如果 API 操作不支持 ARN，请使用 * 通配符指定操作可以影响所有资源。

Condition：条件是可选的。它们可以用于控制策略生效的条件。

由此可以看出，

第一、要想进行资源隔离，resource是关键。但问题来了，就如上面所说，并不是所有操作都支持资源级权限。

第二、即使有些操作是支持资源级权限的，那么怎么唯一标示一个资源或一批资源呢？AWS使用Amazon 资源名称 (ARN)来标示资源。

Amazon Elastic Compute Cloud (Amazon EC2) 的ARN 样例

arn:aws:ec2:region:account-id:customer-gateway/cgw-id

arn:aws:ec2:region:account_id:dedicated-host/host_id

arn:aws:ec2:region:account-id:dhcp-options/dhcp-options-id

arn:aws:ec2:region::p_w_picpath/p_w_picpath-id

arn:aws:ec2:region:account-id:instance/instance-id

arn:aws:iam::account:instance-profile/instance-profile-name

arn:aws:ec2:region:account-id:internet-gateway/igw-id

arn:aws:ec2:region:account-id:key-pair/key-pair-name

arn:aws:ec2:region:account-id:network-acl/nacl-id

arn:aws:ec2:region:account-id:network-interface/eni-id

arn:aws:ec2:region:account-id:placement-group/placement-group-name

arn:aws:ec2:region:account-id:route-table/route-table-id

arn:aws:ec2:region:account-id:security-group/security-group-id

arn:aws:ec2:region:account-id:snapshot/snapshot-id

arn:aws:ec2:region:account-id:subnet/subnet-id

arn:aws:ec2:region:account-id:volume/volume-id

arn:aws:ec2:region:account-id:vpc/vpc-id

arn:aws:ec2:region:account-id:vpc-peering-connection/vpc-peering-connection-id

arn:aws:ec2:region:account-id:vpn-connection/vpn-id

arn:aws:ec2:region:account-id:vpn-gateway/vgw-id

这里我们看到，大部分资源是使用ID来唯一标示的，但是ID是创建资源时，由AWS自动生成的，没什么可以利用的规律。这个问题就有点棘手了。

下面我们针对几种场景来试着解决一下上面提出的问题。

VPC隔离

目标：每个用户创建、管理并控制自己的VPC。

我们先看一下VPC的操作（仅限VPC，暂不包括VPC下的组件）：

DescribeVpcs、CreateVpc、DeleteVpc、ModifyVpcAttribute

首先所有describe操作都不支持资源级权限，所以想要互相看不见暂时办不到。

很不幸，上面所有这些操作都不支持资源级权限。

所以，我建议，VPC由管理员（有权限的用户）统一管理，其他用户只读。

VPC中大部分组件的删除操作可以支持资源级权限。但如上面所说，大部分资源都是以ID来唯一标示的，VPC下面的组件有很多，而且是动态的，随时增加，那有没有办法可以标示出这些组件是属于我的呢。

答案是肯定的，AWS提供Tag来给资源打标签，我们可以规定大家按一定的规则来给资源加上Tag，比如加上（creator:username）。那么在进行VPC组件删除操作的时候就可以通过condition条件ec2:ResourceTag/tag-key进行控制。但这方案也有一定缺陷，因为Tag是会被任何有权限的用户修改的，别的用户改了这个资源的Tag，或者你自己改了这个Tag，那么你就不能继续限制对它的操作了。

subnet子网的删除操作是不支持资源级权限的。同样建议子网定义由专门的网络管理员操作。

只允许客户在指定的VPC中创建和管理虚机

还是一样，先来看一下有关虚机的操作：

RunInstances、StartInstances、RebootInstances、StopInstances、TerminateInstances

1）创建虚机：

RunInstances 是支持资源级权限的，它支持：

Image：使用什么样的镜像

Key pair：使用哪个key pair

Security group：使用哪个安全组

Subnet：使用哪个子网

这里没有VPC，但是有subnet，我们再看一下subnet支持的condition。

ec2:AvailabilityZone

ec2:Region

ec2:ResourceTag/tag-key

ec2:Vpc

这里是有VPC的。所以在指定的VPC中创建虚机是可以的。

2）管理虚机

StartInstances、RebootInstances、StopInstances、TerminateInstances

这些操作是不能限定VPC的，可以限定单台虚机资源，但这样就达不到我们想要的效果。还好这些操作的condition条件都有ec2:ResourceTag/tag-key。同样使用和上面相同的方法，对我们自己的虚机打上我们的Tag，我们就可以限定只有我自己才能操作这些我打了tag的虚机。

一个大问题

虽然我们可以给资源打tag，但是正如上面所说，有一个大问题，我们怎么阻止其他用户修改我的tag呢？

我们先来看一下ec2里Tag的相关操作：

CreateTags、DeleteTags。这两个操作都是支持资源级权限的。我们是否也可以使用ec2:ResourceTag/tag-key来隔离各个用户的操作呢。看上去好像可以。但这里有一个前提，是你先要有一个tag-key，例如creator:username。那么创建这个tag的时候你是不能用conditionec2:ResourceTag/creator ：username的，因为初始情况，是一个tag都没有的，所以加了这个condition，你就无法创建tag。那么只能不加，不加的话，你就无法限制其他用户对tag的修改。但DeleteTags你可以使用这种方法，来限制其他用户的删除。

看到这里其实感觉有点悖论，是先有鸡还是先有蛋的问题。或者把create 和 modify操作分开的话，也可以部分解决这个问题，但不幸的是这两个操作也不是分开的。

但我们还是找到了一种稍微折中一点的办法。放弃一些tag使用的功能，换来这个问题的解决。思路就是做到只能创建，不能修改。AWS CreateTags 创建Tag是支持一种condition ec2:CreateAction，可以限定只有在虚机创建的时候可以创建tag，创建完以后，你就不能修改和新增其他tag了。这样通过控制tag的使用，达到了管理tag的效果。

写到这里，主要场景和解题思路已经讲完了。

下面我们来实操一下。

创建两个用户，不要分配权限。用户管理员创建两个VPC，在每个VPC里创建一个子网。下面来创建策略

{

"Version":"2012-10-17",

"Statement": [

{

//基本ec2查询操作和一些创建虚机必要的，但不涉及资源权限的操作

"Effect":"Allow",

"Action": [

"ec2:Describe*",

"ec2:AttachVolume",

"ec2:CreateVolume",

"ec2:AttachNetworkInterface",

"ec2:DetachVolume",

"ec2:DeleteVolume"

],

"Resource": "*"

},

{

//限定只能在虚机创建时，创建tag

"Effect":"Allow",

"Action": [

"ec2:CreateTags"

],

"Resource":"arn:aws:ec2: region:account:*/*",

"Condition": {

"StringEquals": {

"ec2:CreateAction": [

"RunInstances",

"CreateVolume"

]

}

}

},

{

//限定当该虚机的creator标签等于当前用户时，才能进行该虚机的操作。

"Effect":"Allow",

"Action": [

"ec2:RebootInstances",

"ec2:StartInstances",

"ec2:StopInstances",

"ec2:TerminateInstances"

],

"Condition": {

"StringEquals": {

"ec2:ResourceTag/creator": "${aws:username}"

}

},

"Resource": "*"

},

{

//限定当前用户只能在指定的vpc中启动虚机

"Effect":"Allow",

"Action":"ec2:RunInstances",

"Resource":"arn:aws:ec2: region:account:subnet/*",

"Condition": {

"StringEquals": {

"ec2:Vpc":"arn:aws:ec2: region:account:vpc/vpc-id"

}

}

},

{

//其他必要的虚机启动资源授权

"Effect":"Allow",

"Action":"ec2:RunInstances",

"Resource": [

"arn:aws:ec2:eu-central-1::p_w_picpath/ami-*",

"arn:aws:ec2:eu-central-1:286883986851:volume/*",

"arn:aws:ec2:eu-central-1:286883986851:network-interface/*",

"arn:aws:ec2:eu-central-1:286883986851:key-pair/*",

"arn:aws:ec2:eu-central-1:286883986851:security-group/*"

]

}

]

}

更换vpc-id，创建另一个策略。将两个策略分别分配给两个用户。

然后就可以测试效果了。大家自己动动手吧。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。