Understanding Google Cloud IAM Policy - is it more than an extra layer

Question

I am trying to understand Policy and bindings in Google Cloud IAM.

I came across this command:

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

Can you confirm the following statements:

1. 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?

2. This iam service-accounts get-iam-policy <Service Account> returns an eTag, and from my understanding it is a way of concurrency controlling the Policy this Service Account belongs to?

3. So I guess this command is only used, by the system when checking if a Service Account already belongs to Policy?

4. A Service Account can belong to only one binding, that belongs to a Policy?

5. A Policy is just an extra structural organisational layer on-top of Roles, but it also include the option for bindings with constraints?

Answer 1

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?

A service account can be considered both a resource and an identity.

You can grant roles to other identities to access or manage a service account.

You can grant roles to a service account allowing the service account to access other resources including other service accounts.

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?

The eTag prevents two identities from updating the same policy at the same time for the same resource. First, you read the policy which includes the eTag. Then you modify the policy and reapply. The eTag must match the current eTag. If two identities modify the same policy, the first will succeed and the second will fail. The first update will generate a new eTag which will no longer match the eTag in the second policy.

So I guess this command is only used, by the system when checking if a Service Account already belongs to Policy?

Service accounts do not belong to a policy. Policies are assigned to service accounts (and resources). The command reads the current policy.

A Service Account can belong to only one binding, that belongs to a Policy?

A service account can have only one policy assigned to it. Changes are made by modifying the policy. Remember that a service account can be assigned at the Organization, Folder and Project level in addition to individual resources. In this case the resource can have a policy which includes a service account as a member identity. This is different from a policy that is assigned to a service account.

A Policy is just an extra structural organisational layer on-top of Roles, but it also include the option for bindings with constraints?

I do not understand what you are asking here. A policy consists of roles. A policy is assigned to resources. Constraints are a separate layer that provides restrictions that are applied to resources. If permission is denied by a constraint, then that overrides an allow permission.

Answer 2

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 is not true)

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? (this is not true)

So I guess this command is only used, by the system when checking if a Service Account already belongs to Policy? (this is true)

A Service Account can belong to only one binding, that belongs to a Policy? (this is not true)

A Policy is just an extra structural organisational layer on-top of Roles, but it also include the option for bindings with constraints? (this is not true)