Tag鉴权 - 弹性容器实例

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

如何使用？

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

打开“AliyunECIFullAccess”，即可看到如下内容：

  "Version": "1",
  "Statement": [
    {
      "Action": "eci:*",
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "ecs:DescribeSecurityGroups"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVSwitches",
        "vpc:DescribeVpcs",
        "vpc:DescribeEipAddresses"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}

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

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

{
  "Version": "1",
  "Statement": [
    {
      "Action": "eci:*",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "eci:tag/name": "liumi",
          "eci:tag/env": "test"
        }
      }
    },
    {
      "Action": [
        "ecs:DescribeSecurityGroups"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVSwitches",
        "vpc:DescribeVpcs",
        "vpc:DescribeEipAddresses"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}

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

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

进入“用户授权策略”，选择“编辑授权策略”，选择之前建好的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

{
  "Version": "1",
  "Statement": [
    {
      "Action": "eci:*",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "eci:tag/name": "liumi",
          "eci:tag/env": "test",
          "eci:tag/name": "liumi2",
          "eci:tag/env": "pre"
        }
      }
    },
    {
      "Action": [
        "ecs:DescribeSecurityGroups"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVSwitches",
        "vpc:DescribeVpcs",
        "vpc:DescribeEipAddresses"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}

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

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

{
  "Version": "1",
  "Statement": [
    {
      "Action": "eci:*",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
        "StringEquals": {
          "eci:tag/name": "liumi2",
          "eci:tag/env": "pre"
        }
      }
    },
    {
      "Action": [
        "ecs:DescribeSecurityGroups"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVSwitches",
        "vpc:DescribeVpcs",
        "vpc:DescribeEipAddresses"
      ],
      "Resource": "*",
      "Effect": "Allow"
    }
  ]
}