首页 > 程序开发 > 软件开发 > 其他 > 正文
AWS 使用tag进行精细权限控制
2017-07-17 09:17:07       个评论      
收藏    我要投稿

AWS一个账号下面可以通过IAM创建多个用户,但默认情况下,资源是没有用户属性的,一个账号下的资源,只要用户有这种资源的操作权限,那么不过是你自己创建的还是其他用户创建的,你都可以操作。
但在客户的实际使用场景中,有时需要隔离各用户之间的资源。按照AWS的建议,那你需要创建不同的账号,比如你有开发测试资源环境,还有生产资源环境,那么你需要创建两个账号,但创建两个账号,在查询费用的时候不方便,AWS提供consolidateBill的授权方案,可以合并账单。
所以AWS官方是没有一套简单的方法可以实现我们想要的效果的。
 
那在同一个账号下,能不能做到不同用户的资源隔离呢。
通过IAM策略的灵活配置和aws全局变量,可以部分满足一些场景的需求。
  
在看场景之前,我们先了解一下,AWS 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::image/image-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::image/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,创建另一个策略。
将两个策略分别分配给两个用户。
然后就可以测试效果了。大家自己动动手吧。
点击复制链接 与好友分享!回本站首页
上一篇:可并堆和左偏树问题解析
下一篇:生产者和消费者的两种实现方式
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做实用的IT技术学习网站