如何进行Tag鉴权?

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

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

屏幕快照 2019-05-08 下午2.23.23.png打开“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权限的子账号，也可以选择新建。

屏幕快照 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

{ "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" } ] }