全部产品
云市场
云游戏

Tag鉴权

更新时间:2019-12-10 17:31:11

此前ECI已经支持通过资源组对资源进行管理,并支持子账号的资源组鉴权。如今ECI又新增了一种新的子账号鉴权方式:Tag鉴权。

如何使用?

1、进入RAM控制台,进入“策略管理”,选择“系统策略”,搜索关键字“ECI”。

屏幕快照 2019-05-08 下午2.23.23.png打开“AliyunECIFullAccess”,即可看到如下内容:

  1. "Version": "1",
  2. "Statement": [
  3. {
  4. "Action": "eci:*",
  5. "Resource": "*",
  6. "Effect": "Allow"
  7. },
  8. {
  9. "Action": [
  10. "ecs:DescribeSecurityGroups"
  11. ],
  12. "Resource": "*",
  13. "Effect": "Allow"
  14. },
  15. {
  16. "Action": [
  17. "vpc:DescribeVSwitches",
  18. "vpc:DescribeVpcs",
  19. "vpc:DescribeEipAddresses"
  20. ],
  21. "Resource": "*",
  22. "Effect": "Allow"
  23. }
  24. ]
  25. }

这是系统生成的ECI full权限。

2、接下来,我们选择“新建授权策略”,选择“AliyunECIFullAccess”为模板,修改内容如下:

  1. {
  2. "Version": "1",
  3. "Statement": [
  4. {
  5. "Action": "eci:*",
  6. "Resource": "*",
  7. "Effect": "Allow",
  8. "Condition": {
  9. "StringEquals": {
  10. "eci:tag/name": "liumi",
  11. "eci:tag/env": "test"
  12. }
  13. }
  14. },
  15. {
  16. "Action": [
  17. "ecs:DescribeSecurityGroups"
  18. ],
  19. "Resource": "*",
  20. "Effect": "Allow"
  21. },
  22. {
  23. "Action": [
  24. "vpc:DescribeVSwitches",
  25. "vpc:DescribeVpcs",
  26. "vpc:DescribeEipAddresses"
  27. ],
  28. "Resource": "*",
  29. "Effect": "Allow"
  30. }
  31. ]
  32. }

其实就是在“AliyunECIFullAccess”的基础上,增加了子账号的tag限制(即用户只能操作同时满足name=liumi,env=test的资源。示例中的tag仅做参考,用户可自定义)。这个授权策略意味着,授权的子账号拥有带指定tag的ECI的full权限,而无法操作带其他tag的ECI资源。

3、接下来就是授权,进入“用户管理”,选择需要设置tag权限的子账号,也可以选择新建。

屏幕快照 2019-05-08 下午1.59.58.png

进入“用户授权策略”,选择“编辑授权策略”,选择之前建好的tag策略即可。

常见使用场景

以上文中的子账号为例,预期的结果如下:

CreateContainerGroup

  • 创建没有添加tag,鉴权不通过。
  • 创建传入不匹配的tag,鉴权不通过。
  • 创建传入完全匹配的tag,鉴权通过。
  • 创建传入tag包含授权tag,鉴权通过。

RestartContainerGroup

  • 操作大账号下,tag与自己授权不匹配的eci,鉴权不同通过。
  • 操作大账号下,tag与自己授权匹配的eci,鉴权通过。
  • 操作tag子账号下匹配的eci,鉴权通过。

ExportContainerGroupTemplate

  • 操作大账号下,tag与自己授权不匹配的eci,鉴权不同通过。
  • 操作大账号下,tag与自己授权匹配的eci,鉴权通过。
  • 操作tag子账号下匹配的eci,鉴权通过。

ExecContainerCommand

  • 操作大账号下,tag与自己授权不匹配的eci,鉴权不同通过。
  • 操作大账号下,tag与自己授权匹配的eci,鉴权通过。
  • 操作tag子账号下匹配的eci,鉴权通过。

DescribeContainerLog

  • 操作大账号下,tag与自己授权不匹配的eci,鉴权不同通过。
  • 操作大账号下,tag与自己授权匹配的eci,鉴权通过。
  • 操作tag子账号下匹配的eci,鉴权通过。

DescribeContainerGroups

  • 没有传入tag,但是传入了资源id,id的tag有不满足的,鉴权不通过。
  • 没有传入tag,但是传入了资源id,id的tag全部匹配,鉴权通过。
  • 用户传入tag,但是没有传入资源id,tag与账号不匹配,鉴权不通过。
  • 用户传入tag,但是没有传入资源id,tag与账号匹配,鉴权通过。
  • 用户既传入了tag,又传入了资源id,资源id的自身tag作为鉴权,用户传入的tag只作为单纯的过滤条件。
  • 用户既没有传入tag,又没有传入资源id,即便传了其他的过滤条件,也直接报鉴权不通过,这种情况需要用户自己显式地指定tag。

注:该查询接口鉴权不通过的时候会统一返回空,不报错。

UpdateContainerGroup

  • 更新tag不匹配的eci,鉴权不通过。
  • 更新tag匹配的eci,且不更新tag,鉴权通过。
  • 更新tag匹配的eci,且更新tag,且不具备新tag的权限,鉴权不通过。
  • 更新tag匹配的eci,且更新tag,且具备新tag的权限,鉴权通过。

这种情况其实比较复杂

由于用户更新了tag,需要确保用户分别具有更新前后的tag的权限。怎么保证用户具有更新前后的权限?

会想到两种操作:

第一种:直接在现有的权限下两个tag

  1. {
  2. "Version": "1",
  3. "Statement": [
  4. {
  5. "Action": "eci:*",
  6. "Resource": "*",
  7. "Effect": "Allow",
  8. "Condition": {
  9. "StringEquals": {
  10. "eci:tag/name": "liumi",
  11. "eci:tag/env": "test",
  12. "eci:tag/name": "liumi2",
  13. "eci:tag/env": "pre"
  14. }
  15. }
  16. },
  17. {
  18. "Action": [
  19. "ecs:DescribeSecurityGroups"
  20. ],
  21. "Resource": "*",
  22. "Effect": "Allow"
  23. },
  24. {
  25. "Action": [
  26. "vpc:DescribeVSwitches",
  27. "vpc:DescribeVpcs",
  28. "vpc:DescribeEipAddresses"
  29. ],
  30. "Resource": "*",
  31. "Effect": "Allow"
  32. }
  33. ]
  34. }

这种做法其实是错误的,这实际上是把权限变小了,导致的结果是前后都不匹配。后面这种做法才是正确的。

第二种,给子账号再添加一个独立的权限:

  1. {
  2. "Version": "1",
  3. "Statement": [
  4. {
  5. "Action": "eci:*",
  6. "Resource": "*",
  7. "Effect": "Allow",
  8. "Condition": {
  9. "StringEquals": {
  10. "eci:tag/name": "liumi2",
  11. "eci:tag/env": "pre"
  12. }
  13. }
  14. },
  15. {
  16. "Action": [
  17. "ecs:DescribeSecurityGroups"
  18. ],
  19. "Resource": "*",
  20. "Effect": "Allow"
  21. },
  22. {
  23. "Action": [
  24. "vpc:DescribeVSwitches",
  25. "vpc:DescribeVpcs",
  26. "vpc:DescribeEipAddresses"
  27. ],
  28. "Resource": "*",
  29. "Effect": "Allow"
  30. }
  31. ]
  32. }