Service Accounts in GCP – Kinda like an AWS Role, but still different

For advanced technology seminars on AWS and other technologies, please visit TekSeminars.com

Also see Roles and Policies in GCP

IAM identities can be divided into two broad categories – user identities and programmatic identities. In GCP, there are no native user identities – all users are pulled in from an external identity provider. There is a ‘wrapper’ called cloud identity – which serves as a type of native ‘user’ identity – but again, it is merely a wrapper on an existing gSuite identity.

Concept	AWS	Google Cloud
Programmatic identity	IAM role and instance profile	Cloud IAM service account
User identity	Managed in IAM. Identity federated to external identity management system.	Managed outside Cloud IAM. Identity federated to external identity management system.

Service Account – Username / Password?

In GCP, a service account (email) is like a username. The password that goes along with it is the private key (e.g. p12 key for the service account)

What is a ‘job’ in the context of something running on cloud infrastructure?

A job can be a VM, it can be an app on a VM or a cloud function.

What is a service account in GCP? Why do you need one?

One way to think about it as a Programmatic Identity. The biggest confusion is caused by the fact that a Service Account can be both – a resource and as an identity.  When thinking of a service account as a resource,  one can grant roles to other users to access or manage that service account.

When used as an identity (think programmatic identity), a service account is used for:

1. Running workloads on virtual machines (VMs).
2. Running workloads on on-premises workstations or data centers that call Google APIs.
3. Running workloads which are not tied to the lifecycle of a human user.

Isn’t it like a ‘Role’ in AWS?

Yes – very similar. Except, in AWS, the role is meant to be assumed by any resource – including an EC2 or an IAM user. In GCP, the service account is only meant to be ‘assumed’ (not really assumed, more ‘assigned’) – to an actual resource like a VM on a Compute Engine.

What GCP services allow you to run jobs under service accounts?

Some Google Cloud services, such as Compute Engine, App Engine, or Cloud Functions, allow you to deploy a job (such as a VM or a Function) that runs as the identity of a service account.

Properties of Service Accounts

• Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
• Service accounts do not have passwords, and cannot log in via browsers or cookies.
• Service accounts are not members of your G Suite domain, unlike user accounts.

Designing a correct service account

Some questions to ask before creating your service account:

• What resources can the service account access? This will decide the type of role to assign to the service account
• What permissions does the service account need? This will decide whether to use a predefined role or a primitive role (see this post to understand the different role types and policy types in google cloud) or create a new custom role.
• Where will the code that assumes the identity of the service account be running: on Google Cloud Platform or on-premises? – If on premises, the user needs to manage the access key for the service account.

Summary

Service accounts are conceptually similar to AWS roles, but have differences – especially in the way they are implemented (associated with RSA key pairs).  Using IAM roles, one can create service accounts that can access specific resources from either on premises or natively from GCP.

Need assistance with your GCP or AWS security audits or ongoing efforts?