Service Accounts in GCP

Also read - 2 minute Security Solution for GCP Environments

Overview

Along with understanding the GCP Project boundary, Service accounts are key to understanding the day to day operational aspects of Google Cloud Platform.

Service Accounts are an Identity — and a resource

This is a bit confusing for some. This post will help clarify with a couple of examples.

Service Accounts in GCP as an Identity — ‘the resource assumes the identity’

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 Accounts in GCP 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).

Privilege Escalation - Service Accounts can access EVERYTHING (in theory) under the GCP organization

When you use the built in GCP service accounts inside a project, the service account has the PROJECT EDITOR privilege. This allows it to create and delete a variety of project resources.

In general, it is important to realize that a service account's scope is not limited to the project in which it was created. It's scope can be much wider and is based on the IAM binding you provide it with.

For example - if you were to create a Service Account and create an IAM Bindings (role) that was the SecruityAdmin in GCP. This would give the service account read access to every folder and project under the parent admin, and in a lot of cases, write access (setIAMPolicy access).

Some Role Bindings to be extra careful with include the - Organization Administrator, Project Owner (more on this here) and Security Admin.

Suffice it to say that a Security Admin role is as close to a GODLIKE GCP IAM Admin role and to be used with caution.

How Many Service Accounts? One or many?

As many as you like. Think in terms of a FEW Organization management (maintenance) Service Accounts and LOTS of application specific service accounts (one each for cloud storage, cloud sql etc. within your project).

Authenticate as another SA?

Resources, applications, users, and even service accounts can all impersonate a service account. Impersonating a service account means that you are able to authenticate as the service account, and now have whatever permissions were granted to it.

Logs will show any actions as being performed by the service account. It’s important to understand impersonation, because it could be used in unexpected ways in your environment to escalate privileges.

An SA for Short Lived Credentials?

Just like AWS provides an 'assume role' capability for short lived access, GCP too has the ability to define short lived service account access. More on that here SAs for short term credentials.

Automation - Creating a project using a service account

You can use a service account to automate project creation. Like user accounts, service accounts can be granted permission to create projects within an organization. Service accounts are not allowed to create projects outside of an organization and must specify the parent resource when creating a project. Service accounts can create a new project using the gcloud tool or the projects.create() method.

Restricting Access Scopes

The only thing stopping the default service account from being able to utilize all of its permissions are the “access scopes” assigned to the virtual machine. This is a control that dictates which APIs the service account is able to access. So, if the service account is granted access to the Storage API in the IAM policy, the account still cannot access the Storage API if the access scopes do not include the Storage API. Here is an example the access scope options available in the GCP console:

Shared Services Projects and Service Accounts

Service accounts should be placed in a shared services project.
KMS Keys also belong in this shared services project.

Compromise

If one of your workloads has been compromised while running the default service account and it also has full scopes enabled, then it could easily enumerate other service accounts in the same project, and even impersonate those service accounts. This is because the default service account has project editor permissions. Those permissions include the ability to impersonate other service accounts in that project.

If the same project contains service accounts with elevated bindings (permissions at the Folder or Organization levels), then that service account can be easily impersonated by the compromised workload. Once the workload is used to impersonate it, that account is now only limited by the permissions granted to the service account with elevated bindings. This could include adding new users, tearing down VPC Service Controls (or other security controls), and launching its own workloads.

An alternative to proliferating Service Accounts?

With each SA, you get a JSON key, which can be considered a long-term access key. The more Service Accounts you create, the more of these JSON keys you are left maintaining.

To avoid this multiplicity of JSON keys, you can also use tokens — or short lived access to GCP resources (usually, to built in service accounts). More on that here SAs for short term credentials.

Recommendations and Best Practices for Service Accounts in GCP

Due to the dangerous nature of the default service account running with full scopes assigned, we recommend doing the following in your GCP environment:

No wide scope service accounts (i.e. not spanning across multiple LOBs). Use ONE SA for each LOB.
Designate a SINGLE project that will be used for any accounts that require elevated bindings. Keep that project as secure as possible and do not populate it with any public workloads.
Keep track of who or what can impersonate service accounts. If you lose track of this, privilege escalation becomes a much larger risk.
Don’t use the default service accounts for your workloads. If your workload does not need to access GCP APIs, then remove the service account all together.
Don’t create bindings that include primitive roles whenever possible. These are broad, and permissions should be more granular.

Summary

Service accounts, along with the Project Boundary, are key to understanding the day to day operational aspects of Google Cloud Platform.

Appendix A - More on Service Accounts and Impersonation

A service account in GCP is an identity that is provided to allow applications to authenticate and make calls to the GCP APIs. It does not use passwords, but uses RSA keys to authenticate. If you are familiar with IAM roles in AWS, this is the same concept for GCP. When you assign a service account to a resource, Google automatically rotates the keys for you. This is better than having to store static credentials in your code.

One important concept to keep in mind for GCP is that a service account must be created in a project. However, a service account could be given bindings at a level higher than a project, such as permissions at the Folder or even Organization levels.

I will refer to these types of permissions as “elevated bindings.” These are dangerous, because the permissions at higher levels could give you access to other security controls, and all the projects under that structure will inherit the permissions.

There are three ways to impersonate a service account to access Google APIs:

Authentication using RSA private keys
Authorization using Cloud IAM policies
Deploying jobs on Google Cloud servicesImpersonating a service account

Also see Auditing AWS Account Security.

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