Applications and Service Accounts

Service Accounts in GCP

Service accounts are ubiquitous in GCP – there are built in SAs (for most major services) and those that you can create yourself (using gcloud, the console or cloud shell). To get an understanding of SA basics, read this post first. And this one to understand IAM bindings to service accounts.

Applications ASSUME the access of the SA

Applications assume the access privileges of a service account.  It is best to learn service accounts through a set of gCloud commands.

Creating a Service Account

gcloud iam service-accounts create my-sa-with-bucket-access --display-name "SA with bucket access"

$ gcloud iam service-accounts list  --> Will show you the newly created SA

Launching a VM with the Service Account

When you create a Compute Instance (or app engine instance) to host your application, you will have the option to run it under a ‘Service Account’. From the drop down list, pick your newly created SA.

That’s it. Now the VM runs with the access privileges of this service account. Hence, any app hosted on this VM will have access to the bucket that the SA is allowed to access.

For instance, to grant  this particular SA, bucket access to ALL BUCKETS  (and other resources) within a project (the command below makes this SA an EDITOR on the project):

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

If you just wanted to grant access to storage buckets, as opposed to ALL resources, you would use something like:

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

Creating IAM Bindings between Users and SAs, and SAs and Projects (or any resource)

IAM User bound to  Service Account (as a Resource)

gcloud iam service-accounts add-iam-policy-binding my-serviceaccount@somedomain.com --member='user:test-user@gmail.com' --role='roles/editor'

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:test-proj1@example.domain.com' --role='roles/editor'

Service Account (as an identity) bound to a project

The operative word here is ‘gcloud projects’ – This is what says that the SA is being bound to a PROJECT.

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

Summary

This is an overview of how applications running on compute engine instances (or app engine or app engine flex) can assume the privileges (roles) of a service account. You can use existing service accounts (built in compute engine Service Account for example), or define your own service account, with very specific roles assigned (e.g. access to a storage bucket or access to cloud sql).

Need an experienced AWS/GCP/Azure Professional to help out with your Public Cloud Strategy? Set up a time with Anuj Varma.