理解Google Cloud IAM策略--它不仅仅是一个额外的层吗

Question

我正在尝试理解Google Cloud IAM中的策略和绑定。

我遇到了这样的命令：

iam service-accounts get-iam-policy <Service Account>

你能否证实以下说法：

>

服务帐户既可以是身份，也可以是资源，因此，就角色而言，服务帐户是资源，而在策略中，它是身份？

这个iam service-accounts get-iam-policy 返回一个eTag，根据我的理解，它是一种并发控制该服务帐户所属策略的方法？

所以我想这个命令只有在系统检查服务帐户是否已经属于策略时才会使用？

一个服务帐户只能属于一个属于策略的绑定？

策略只是在角色之上的一个额外的结构组织层，但它还包括有约束的绑定选项？

Answer 1

服务帐户既可以是一个身份，也可以是一个资源，所以就角色而言，服务帐户是一个资源，而在策略中，它是一个身份？（这不是事实）

这个iam service-accounts get-iam-policy返回一个eTag，根据我的理解，它是对这个服务帐户所属的策略进行并发控制的一种方式？（这不是事实）

所以我想这个命令只有在系统检查服务帐户是否已经属于策略时才会使用？（这是事实）

一个服务帐户只能属于一个属于策略的绑定？（这不是事实）

策略只是在角色之上的一个额外的结构组织层，但它还包括有约束的绑定选项？（这不是事实）

Answer 2

服务帐户既可以是一个身份，也可以是一个资源，所以就角色而言，服务帐户是一个资源，而在策略中，它是一个身份？

服务帐户既可以被视为资源，也可以被视为标识。

您可以将角色授予其他标识以访问或管理服务帐户。

您可以向服务帐户授予角色，允许该服务帐户访问其他资源，包括其他服务帐户。

这个iam service-accounts get-iam-policy返回一个eTag，根据我的理解，它是对这个服务帐户所属的策略进行并发控制的一种方式？

eTag防止两个标识同时为同一资源更新同一策略。首先，您阅读包含ETAG的政策。然后修改策略并重新应用。eTag必须与当前eTag匹配。如果两个标识修改了相同的策略，则第一个标识将成功，第二个标识将失败。第一次更新将生成一个新的eTag,该eTag将不再与第二个策略中的eTag匹配。

所以我想这个命令只有在系统检查服务帐户是否已经属于策略时才会使用？

服务帐户不属于策略。策略被分配给服务帐户（和资源）。该命令读取当前策略。

一个服务帐户只能属于一个属于策略的绑定？

一个服务帐户只能分配一个策略。通过修改策略进行更改。请记住，除了单个资源外，还可以在组织、文件夹和项目级别分配服务帐户。在这种情况下，资源可以有一个策略，其中包括一个服务帐户作为成员标识。这与分配给服务帐户的策略不同。

策略只是在角色之上的一个额外的结构组织层，但它还包括有约束的绑定选项？

我不明白你在这里问什么。策略由角色组成。将策略分配给资源。约束是一个单独的层，它提供了应用于资源的限制。如果权限被约束拒绝，则将重写allow权限。