了解 Google Cloud IAM 政策 - 它不仅仅是一个额外的层
Understanding Google Cloud IAM Policy - is it more than an extra layer
我正在尝试了解 Google Cloud IAM 中的策略和绑定。
我遇到了这个命令：
iam service-accounts get-iam-policy <Service Account>
能否证实以下说法：
服务帐户既可以是身份又可以是资源，所以对于角色而言，服务帐户是资源，而在策略中它是身份？
这个 iam service-accounts get-iam-policy <Service Account> returns 一个 eTag，据我了解，这是一种并发控制此服务帐户所属策略的方式？
所以我猜这个命令仅在系统检查服务帐户是否已属于策略时使用？
一个服务帐户只能属于一个绑定，即属于一个策略？
策略只是角色之上的一个额外的结构组织层，但它还包括带有约束的绑定选项？
A Service Account can be both an Identity and a Resource, so in
regards to Roles a Service Account is a Resource and in a Policy it is
an Identity?
服务帐户可以被视为资源和身份。
您可以将角色授予其他身份以访问或管理服务帐户。
您可以向服务帐户授予角色，允许该服务帐户访问其他资源，包括其他服务帐户。
This iam service-accounts get-iam-policy returns an
eTag, and from my understanding it is a way of concurrency controlling
the Policy this Service Account belongs to?
eTag 可防止两个身份同时针对同一资源更新同一策略。首先，您阅读包含 eTag 的政策。然后您修改策略并重新应用。 eTag 必须与当前 eTag 匹配。如果两个身份修改同一个策略，第一个会成功，第二个会失败。第一次更新将生成一个新的 eTag，它将不再与第二个策略中的 eTag 匹配。
So I guess this command is only used, by the system when checking if a
Service Account already belongs to Policy?
服务帐户不属于策略。策略分配给服务帐户（和资源）。该命令读取当前策略。
A Service Account can belong to only one binding, that belongs to a
Policy?
一个服务帐户只能分配一个策略。通过修改策略进行更改。请记住，除了单个资源之外，还可以在组织、文件夹和项目级别分配服务帐户。在这种情况下，资源可以具有包含服务帐户作为成员身份的策略。这与分配给服务帐户的策略不同。
A Policy is just an extra structural organisational layer on-top of
Roles, but it also include the option for bindings with constraints?
我不明白你在这里问什么。策略由角色组成。将策略分配给资源。约束是一个单独的层，提供应用于资源的限制。如果权限被约束拒绝，则会覆盖允许权限。
服务帐户既可以是身份又可以是资源，那么对于角色而言，服务帐户是资源，而在策略中它是身份？
（这不是真的）
这个 iam service-accounts get-iam-policy returns 一个 eTag，据我了解，这是一种并发控制此服务帐户所属策略的方式？
（这不是真的）
所以我猜这个命令只是在检查服务帐户是否已经属于策略时由系统使用？
（这是真的）
一个服务帐户只能属于一个绑定，即属于一个策略？
（这不是真的）
策略只是角色之上的额外结构组织层，但它还包括用于约束绑定的选项？
（这不是真的）
我正在尝试了解 Google Cloud IAM 中的策略和绑定。
我遇到了这个命令：
iam service-accounts get-iam-policy <Service Account>
能否证实以下说法：
服务帐户既可以是身份又可以是资源，所以对于角色而言，服务帐户是资源，而在策略中它是身份？
这个
iam service-accounts get-iam-policy <Service Account>returns 一个 eTag，据我了解，这是一种并发控制此服务帐户所属策略的方式？所以我猜这个命令仅在系统检查服务帐户是否已属于策略时使用？
一个服务帐户只能属于一个绑定，即属于一个策略？
策略只是角色之上的一个额外的结构组织层，但它还包括带有约束的绑定选项？
A Service Account can be both an Identity and a Resource, so in regards to Roles a Service Account is a Resource and in a Policy it is an Identity?
服务帐户可以被视为资源和身份。
您可以将角色授予其他身份以访问或管理服务帐户。
您可以向服务帐户授予角色，允许该服务帐户访问其他资源，包括其他服务帐户。
This iam service-accounts get-iam-policy returns an eTag, and from my understanding it is a way of concurrency controlling the Policy this Service Account belongs to?
eTag 可防止两个身份同时针对同一资源更新同一策略。首先，您阅读包含 eTag 的政策。然后您修改策略并重新应用。 eTag 必须与当前 eTag 匹配。如果两个身份修改同一个策略，第一个会成功，第二个会失败。第一次更新将生成一个新的 eTag，它将不再与第二个策略中的 eTag 匹配。
So I guess this command is only used, by the system when checking if a Service Account already belongs to Policy?
服务帐户不属于策略。策略分配给服务帐户（和资源）。该命令读取当前策略。
A Service Account can belong to only one binding, that belongs to a Policy?
一个服务帐户只能分配一个策略。通过修改策略进行更改。请记住，除了单个资源之外，还可以在组织、文件夹和项目级别分配服务帐户。在这种情况下，资源可以具有包含服务帐户作为成员身份的策略。这与分配给服务帐户的策略不同。
A Policy is just an extra structural organisational layer on-top of Roles, but it also include the option for bindings with constraints?
我不明白你在这里问什么。策略由角色组成。将策略分配给资源。约束是一个单独的层，提供应用于资源的限制。如果权限被约束拒绝，则会覆盖允许权限。
服务帐户既可以是身份又可以是资源，那么对于角色而言，服务帐户是资源，而在策略中它是身份？ （这不是真的）
这个 iam service-accounts get-iam-policy returns 一个 eTag，据我了解，这是一种并发控制此服务帐户所属策略的方式？ （这不是真的）
所以我猜这个命令只是在检查服务帐户是否已经属于策略时由系统使用？ （这是真的）
一个服务帐户只能属于一个绑定，即属于一个策略？ （这不是真的）
策略只是角色之上的额外结构组织层，但它还包括用于约束绑定的选项？ （这不是真的）