Google Cloud IAM for Security Teams

Identity and Access Management (IAM) is an important piece of the cloud puzzle and it’s usually a source of headaches from a security point of view. Let’s try to give some pointers from a blue team perspective.

If you are a security team that just inherited a bunch of Google Cloud Platform (GCP) accounts, this guide is for you.

Identities and Roles

IAM revolves around the concept of identity: an (authenticated) entity to which authorization grants are applied.

Members

In Google Cloud, identities are called members and are the following:

• A User: defined by a Google Account
• A Group: defined by a Google Group
• A domain: a super group representing all accounts under a gsuite/workspace domain
• A Service Account: an account for an application rather than an end user

To make things spicier, there are also two special members that you are going to hate and you want to make sure they will never be used (unless valid business reasons):

• allAuthenticatedUsers: a special group comprised of everyone on earth with a google account (yes)
• allUser: anyone on the internet, authenticated or not

Roles

You assign (bind) a Role to a Member to grant that identity access to a resource. An example role is resourcemanager.projectCreator:

$ gcloud iam roles list
…
---
description: Access to create new GCP projects.
etag: AA==
name: roles/resourcemanager.projectCreator
stage: GA
title: Project Creator
---
…

Roles are a set of permissions grouped together, each one representing a fine grained operation. You can’t assign permissions directly to members.

An example permission would be resource manager.projects.create:

$ gcloud iam roles describe roles/resourcemanager.projectCreator
description: Access to create new GCP projects.
etag: AA==
includedPermissions:
- resourcemanager.organizations.get
- resourcemanager.projects.create
name: roles/resourcemanager.projectCreator
stage: GA
title: Project Creator

Usually, every cloud service will come with a dedicated set of Roles (not for Google Container Registry).

Custom Roles

As a rule of thumb stick to standard roles, but if you have to bind a role to a member in a high level policy you might want to use a custom role. Custom Roles allows you to group together the specific set of permissions you need.

They are helpful to maintain least privilege because a role bind on a high level policy (like the Organization one) will affect way more resources.

Primitive Roles

There are a bunch of roles you should be wary of: primitive roles. These are Owner, Editor and Viewer. When they are bind on the Project IAM policy they translate to admin, write and read access to everything inside that project.

You want to be wary for two reasons:

1. The set of permissions change over time: when Google release new cloud services, permissions for such services are included in the primitive roles. This means you have an authorization grant that change over time and you have no control over. No bueno.
2. They are a bridge to Access Control List (ACL). ACL are the legacy authorization system for some storage services such as Buckets and Bigquery. In such resources you can assign ACL grants to whoever is bind to a primitive role in the Project. This relationship adds complexity when trying to understand the blast radius of a member.

If you can’t escape using a primitive role, bind them to members that you will use only in “break the glass” scenarios. In practice, you don’t want a team doing their day to day operations as Owners.

IAM Policies (and where to find them)

Roles are bind to members in an IAM Policy. Policies are organized in hierarchical layers (from top to bottom):

• Organization
• Folder
• Project
• Specific Resources.

Bindings will be inherited from top to bottom.

So if you assign Storage Admin to a service account in the Organization IAM Policy, the same grant will be applied to everything down (don’t do that).

You obviously want to be extra careful when binding roles high in the hierarchy as the authorization grant will be quite large. That’s why it’s a good idea to use custom roles to shrink it to just the permissions you need.

Some specific cloud resources, such as Buckets, have their own IAM policy. These are easy to overlook because they don’t have a consistent place in the google cloud admin interface.

The best way to get visibility over all IAM policies is to create a Cloud Asset Inventory (CAI) dump. CAI is, in my opinion, the most useful thing in GCP. It’s an API that will generate a json (or bigquery) dump of all the resources and IAM Policies you are currently running.

The best thing you can do on day one is to set up periodical CAI dumps, and then build your detections on top of them.

Maintain the principle of least privilege

The second best thing is to use the IAM Recommender: a service that monitors how role bindings are actually used to make sure you are not over granting them.

Another helpful trick to know is that you can attach conditions to role bindings. For example you can set an expiration time, or you can scope down the binding to affect only certain resources matching a pattern.

Notes on Service Accounts

Service accounts can be of two types: google managed and user managed.

A user managed service account is one you manually create. To use it, you need to create a private key and embed it into your application. A service account can have multiple keys.

Service Account keys lifecycle is your responsibility: they never really expires, are hard to audit (you don’t see which key has been used from the audit logs). From day one you should start thinking how to keep track of them.

Personally I am a fan of wrapping keys creation into an internal service for your developers to use, but I understand it’s not always possible.

The best alternative is to use google managed service accounts. For example each project will come with a default service account that is used by Google Compute Engine (GCE) services (if the GCE API is enabled).

This means that virtual machines will transparently be identified by that service account, and they are authorized to request short-lived authorization tokens from the internal metadata service. You can configure them to use a service account of your choice and no keys are involved.

Conclusion

To recap:

• scan your IAM policies and make sure that allAuthenticatedUsers and allUsers are never used
• or even better, set up an organizational policy to only allow members from your gsuite/workspace domain
• Use standard roles when the number of affected resources is limited
• Use custom roles when the authorization grant affect too many resources
• Avoid primitive roles
• Do not use Access Control Lists (ACL)
• The higher in the IAM hierarchy, the wider the scope of the authorization grant: use sporadically, be a gatekeeper.
• Set up Cloud Asset Inventory to not miss anything
• Adhere to the least privilege principle with the IAM Recommender and IAM Conditions
• Become a gatekeeper for provisioning Service Accounts keys
• Use the identity of the virtual machines whenever possible
• Are you running Google Kubernetes Engine (GKE)? Take a look at Workload Identity
• Follow service accounts best practices

There is a lot more to say about IAM governance and security best practices. This article’s purpose is to give a high level overview of the main security considerations.

If you are looking for specific advices, let me know. I might have some.

Finally, I highly recommend this fantastic talk by Kat Traxler about primitive roles and IAM quirks in GCP.