Identity and Access Management in Google Cloud

When setting up Google Cloud, one of the first and most important decisions an organization must make is how authentication and user management will be handled. Google Cloud provides two primary, native approaches for managing identities and authentication:

Cloud Identity and Google Workspace.

Cloud Identity is Google Cloud’s standalone IAM service and is typically used when an organization does not rely on Google Workspace for email and collaboration.

Google Workspace, on the other hand, extends beyond IAM to include services such as Gmail, Drive, and Calendar, while also acting as a centralized identity provider for Google Cloud.

-------------------------------------------------------------------------------------------------------------

Google Workspace and Google Cloud Organization

When Google Workspace is linked to Google Cloud, the primary domain used in Google Workspace becomes the Google Cloud Organization. This linkage is important because it establishes a single authoritative identity source across both platforms.

Core IAM Building Blocks in Google Cloud

Google Cloud’s IAM system is built on three foundational components:

• Members

• Roles

• Policies

Together, these components define who can access resources, what actions they can perform, and where those permissions apply.

For DFIR practitioners, IAM is one of the most critical evidence sources. Nearly every meaningful action in Google Cloud—creating resources, modifying configurations, accessing data—requires IAM authorization and therefore leaves IAM-related audit trails.

-------------------------------------------------------------------------------------------------------------

Members: Who Is Requesting Access?

A Member represents an identity that can be granted permissions. Members are treated as objects within Google Cloud and can include:

• Individual users

• Groups

• Service accounts

• Users or groups from Google Workspace

• Users or service accounts from other Google Cloud organizations

• Even external Gmail accounts

Members are typically identified by email address, although permissions can also be assigned at the domain level when managing very large groups of users.

From an investigation standpoint, understanding Members is essential because attackers often abuse service accounts, compromised user credentials, or overly broad group memberships to gain persistent access.

-------------------------------------------------------------------------------------------------------------

Roles: What Actions Are Allowed?

A Role is a collection of permissions grouped together to define what actions a Member can perform. Google Cloud provides three types of roles, each serving a different purpose.

Basic Roles

Basic Roles were introduced early in Google Cloud’s development and include:

• Owner

• Editor

• Viewer

These roles are broad and convenient but often grant far more permissions than necessary.

Predefined Roles

Predefined Roles are created and maintained by Google Cloud and provide fine-grained permission control. Each predefined role is tailored to a specific service or function, allowing organizations to apply the principle of least privilege more effectively.

From a security and DFIR perspective, predefined roles are preferred because:

• Permissions are well-documented

• Scope is limited and predictable

• Over-privileging is easier to detect

Custom Roles

Custom Roles allow organizations to create their own roles by selecting specific permissions. These roles are useful when predefined roles are either too broad or too restrictive.

However, custom roles introduce complexity. Google Cloud has hundreds of individual permissions, and incorrectly assembling them can result in unintended access.

-------------------------------------------------------------------------------------------------------------

Permissions: The Smallest Unit of Access

Permissions are the most granular level of access control in Google Cloud. Each permission corresponds to a specific action on a resource, such as:

• Listing storage buckets

• Creating or deleting storage objects

• Viewing encryption keys

Individually, permissions are rarely useful. Their real value comes from being grouped into roles, which are then applied through policies.

-------------------------------------------------------------------------------------------------------------

Policies: Where Access Is Enforced

A Policy binds together:

• One or more Members

• A Role (which contains permissions)

• A specific Resource

Policies are applied to resources, not to Members. This is a fundamental concept that often confuses administrators and investigators alike.

Unlike some other cloud platforms, you cannot ask Google Cloud “what permissions does this user have?” Instead, you must ask “who has access to this resource?” because permissions are evaluated at the resource level.

-------------------------------------------------------------------------------------------------------------

One of the biggest mental shifts people struggle with in Google Cloud is how permissions actually work. Most of us come from a world like Microsoft Active Directory, where identity management is user-centric. You click on a user, check their group memberships, and boom — you more or less know what they can access.

Google Cloud flips this model on its head.

In Google Cloud, permissions are applied to Resources, not to Members. That single design decision changes everything — especially for incident response.

This means you cannot simply query a user and say:

“Show me everything this user has access to.”

That view doesn’t exist in a clean, centralized way.

Why This Becomes a DFIR Problem

Now imagine you’re in the middle of an incident. You suspect a user account is compromised.

In an on-prem AD environment, you’d immediately:

• Check the user

• Review group memberships

• Identify privilege escalation paths

In Google Cloud, that approach doesn’t work.

Instead, investigators are forced to lean heavily on logs:

• Audit logs

• Access logs

• IAM policy change logs

You’re essentially reconstructing permissions based on behavior, not configuration alone. That’s why logging becomes far more critical in Google Cloud investigations than many teams expect.

-------------------------------------------------------------------------------------------------------------

The Upside: Resource-Focused Investigations

While this model feels painful at first, it does have a huge investigative advantage.

If you already know what was abused — say:

• A storage bucket

• A VM

• A logging sink

• A project

Then Google Cloud’s model actually helps you.

You can:

1. Go directly to the Resource

2. Inspect the IAM Policy attached to it

3. See every Member who has access

4. See exactly what level of access they have

So instead of asking “What can this user access? You ask “Who can access this thing that was abused?”

That shift is incredibly powerful during scoping and impact analysis.

-------------------------------------------------------------------------------------------------------------

Cross-Organization Access: Where It Gets Messy

Here’s where things get uncomfortable.

Google Cloud allows Members from one Organization to have access to Resources in another Organization.

Two key problems come out of this:

1. Your users might have access to external resources you know nothing about

2. If your user accesses a Resource in another Organization, the logs live over there — not with you

So during an investigation, you might see:

• Suspicious authentication

• API usage

• Token activity

…but no corresponding resource access logs, because the activity occurred in another Organization entirely.

This is one of the hardest things to explain to management during an incident:

“Yes, our account did it — but the evidence is stored in someone else’s cloud.”

-------------------------------------------------------------------------------------------------------------

Service Accounts: Same Problem, Bigger Impact

Now let’s make it even more interesting.

Resources in Google Cloud — like VMs — often need to access other Resources. They don’t do this as users. They do it using Service Accounts.

For example:

• A VM needs to read/write to a Storage Bucket

• The VM is assigned a Service Account

• The Storage Bucket has a Policy allowing that Service Account access

From an IAM perspective, Service Accounts are Members. Which means all the same permission challenges apply.

If a Service Account is compromised:

• You still can’t easily list everything it has access to

• You still have to investigate from the Resource side

• You still rely heavily on logs

This is why Service Account abuse is so dangerous in cloud incidents — they’re quiet, persistent, and often over-privileged.

-------------------------------------------------------------------------------------------------------------

Grouping Still Exists — Just Depends Where You Do It

Google Cloud does support grouping (thankfully), but where you create those groups depends on your IAM setup.

• If you’re using Cloud Identity only (IDaaS)→ Groups are created in the Google Cloud IAM console

• If you’re using Google Workspace→ Groups are created in the Workspace Admin console

Functionally, the idea is the same:

• Users are added to groups

• Groups are assigned Roles

• Roles are enforced via Policies on Resources

For enterprises, Workspace-based groups are usually cleaner because:

• Identity already exists

• Group lifecycle is managed centrally

• DFIR teams can reuse security-focused group structures

-------------------------------------------------------------------------------------------------------------

One Critical Requirement People Miss

If you’re linking Google Workspace with Google Cloud, there is one non-negotiable requirement:

You must create the gcp-organization-admins group in Google Workspace and place your Organization Admins inside it.

Without this group:

• Google Cloud will not properly link to Workspace

• IAM inheritance breaks

• Administrative visibility becomes inconsistent

Everything else builds on top of this foundation.

-------------------------------------------------------------------------------------------------------------

DFIR Takeaway

Google Cloud IAM isn’t worse than traditional IAM — it’s different.

• You investigate Resources, not users

• Logs matter more than static permission views

• Service Accounts deserve as much scrutiny as human users

• Cross-Organization access can hide evidence

• Group design directly impacts incident response speed

Once this model clicks, Google Cloud investigations start to feel methodical instead of chaotic.

-------------------------------------------------------------------------------------------------------------

Why IAM Matters So Much for DFIR

IAM is not just an access control mechanism—it is a primary evidence source. It reveals:

• How attackers gained access

• What permissions they abused

• Whether misconfigurations enabled lateral movement

• How persistence was established

--------------------------------------------Dean-----------------------------------------------------------