It took me a while to get a handle on these...This post will hopefully clear up some initial teething issues around creating iam bindings. (Also, read 'Service Accounts in GCP')

IAM bindings are used to answer the question - here is a SPECIFIC bucket (or instance). How do I allow (or block) access to THIS PARTICULAR resource?

The answer is to create an IAM Binding - between the USER (IAM identity) and the RESOURCE.  The way you do this is using the gCloud tool (or gsUtil for a lot of storage specific IAM bindings)

A couple of examples should help clarify the use of gCloud and gsUtil

Storage bucket binding to IAM user

gsutil iam ch user:[email protected]:storageAdmin gs://ex-bucket

Storage bucket binding to a Service Account

gsutil iam ch serviceAccount:test-sa@<PROJECT>.iam.gserviceaccount.com:admin gs://ex-bucket

Compute Engine binding to IAM user (grant compute.admin ON a specific VM to a specific user)

gcloud beta compute instances add-iam-policy-binding my-instance \
      --zone=ZONE --member='user:[email protected]' \
      --role='roles/compute.admin'

Instead of an IAM User, what if we want to bind a service account to a resource?

Yes - you can create the same IAM binding between a Service Account and a  GCP Resource. The beauty of this technique is that service accounts, being super powerful entities, can get access to all contained resources.

For example, if you were to BIND the service account at the PROJECT level (say, you granted it roles/StorageAdmin), that would allow this service account to manage ALL storage buckets inside the project.

Example 1 - Service Account bound to itself?

The operative words here are 'gcloud iam' - This shows that the binding is occurring between an IAM resource and another IAM resource.

gcloud iam service-accounts add-iam-policy-binding test-proj1@example.domain.com --member='serviceAccount:[email protected]' --role='roles/editor'

Example 2 - Service Account (as an identity) bound to a project

The operative word here is 'gcloud projects' - This says that the binding is occurring at a PROJECT level.

gcloud projects add-iam-policy-binding test-proj1@example.domain.com --member='serviceAccount:[email protected]' --role='roles/editor'

Okay - so an IAM user can be bound to a resource. And a service account can be bound to a resource. What about an IAM user being bound to a service account?

Yes - service accounts are RESOURCES as well.  You can bind a user (IAM user) to a service account (resource) as shown below. Again, the operative words are 'gcloud iam'

gcloud iam service-accounts add-iam-policy-binding my-iam-account@somedomain.com --member='user:[email protected]' --role='roles/editor'

Service Accounts are Identities as well as Resources

As shown above, a service account can be used as an IAM Identity to create specific IAM Bindings to resources.

At times, you would use the SA as an identity (to authenticate to GCP resources). For example, if you have a Compute Engine Virtual Machine (VM) running as a service account, you can grant the editor role to the service account (the identity) for a project (the resource).

Service Account As a Resource  — ‘the identity USES the service account as a resource’ 

   At times, you would need another IAM identity to USE an existing service account. In that case, the service account is nothing more than a resource. As an example, you may want to control who can start a compute instance (for which there is an existing service account). All you would do is GRANT the IAM user (the identity) the serviceAccountUser role for the compute engine service account (the resource).

More GCP IAM Bindings - Deeper Dive

An IAM binding has three components — a set of users, a resource and a set of ROLES (permissions) for those users on that resource. The ‘resource’ can sometimes be an identity (e.g. a service account).

So — take the following two examples:

Example 1 — IAM Binding of IAM Users to a PROJECT (resource)

Assign ‘roles/editor’ for all authenticated users on a project with identifier ‘example-project-id-1’

gcloud projects add-iam-policy-binding example-project-id-1 \
      --member='allAuthenticatedUsers' --role='roles/editor'

Example 2— IAM Binding of IAM Users to a Service Account (used as a resource)

gcloud iam service-accounts add-iam-policy-binding my-iam-account@somedomain.com --member='user:[email protected]' --role='roles/editor'

Summary

That's it. GCP IAM bindings sound more convoluted than they actually are. Essentially, if your question is:

'I have this resource (say a storage bucket).. How do I allow a particular user (say [email protected]) access to JUST THIS BUCKET, and NOT ALL BUCKETS?'

You would use an IAM Binding to do this.

How about if you wanted to grant access to ALL storage buckets inside a project? You would still create an IAM Binding - but you would define it at the Project Level (StorageAdmin at the Project Level).

Set up a 1 on 1 appointment with Anuj to assist with your cloud journey.