GCP - IAM

Identities (Principals)

Note: Google Cloud is undergoing a major architectural shift in how it handles identity. While Service Accounts (SAs) as we know them (email-based resources) aren't going away overnight, GCP is increasingly using Resource-Based Identities (using the principal:// and principalSet:// formats) for newer services.

In Google Cloud, an identity (referred to officially as a Principal) is any entity that can be authenticated and granted permissions to access resources.

Google categorizes these into three main buckets: Google-native identities, Federated identities, and Special identifiers.

1. Google-Native Identities

These are managed directly by Google or within a Google-managed directory (like Google Workspace or Cloud Identity).

Google Account (user:): Represents a specific person. It can be a personal @gmail.com account or a managed account from Google Workspace (e.g., [email protected]).
Service Account (serviceAccount:): A "machine identity" meant for applications and workloads. They don't have passwords; they use cryptographic keys or "attested" credentials (like we discussed with Agent Identity).
Google Group (group:): A collection of Google Accounts and Service Accounts. Assigning a role to a group is a best practice, as it simplifies managing access for entire teams.
Domain (domain:): Represents all users within a specific Google Workspace or Cloud Identity domain (e.g., everyone with an @example.com email).

2. Federated Identities (The Zero Trust Pillar)

This is where GCP allows you to bring your own identities from outside Google without needing to sync them into a Google directory. This is how principal:// and SPIFFE are used.

Workload Identity Federation: For software/machines running outside of GCP (e.g., in AWS, Azure, on-prem, or GitHub Actions).
- Format: principal://... (for a specific workload) or principalSet://... (for a group of workloads).
- Example: A GitHub Action runner that needs to deploy code to GCP can be granted a role directly without needing a long-lived Service Account Key.
Workforce Identity Federation: For employees/humans who are managed in an external provider like Okta, Microsoft Entra ID (Azure AD), or Ping Identity.
- This is "syncless"—users don't need a Google Account; they login with their corporate credentials, and GCP recognizes them as a federated principal.

3. Agent Identities (The New Category)

Google has introduced specialized identities for its "Agents" (like Vertex AI Agents).

Agent Engine Identity: Unlike a standard Service Account, this is a managed identity that Google automatically creates for AI agents. It is attested by Google's infrastructure, meaning the identity is tied to the specific, healthy execution of the agent code rather than just a static key.

4. Special Identifiers

These are used to grant broad access, often for public or organization-wide resources.

allUsers: Represents anyone on the internet, authenticated or not. (Use this for public website buckets).
allAuthenticatedUsers: Represents anyone on the internet who is logged into any Google Account (personal or corporate). It doesn't mean "anyone in your company," it means "anyone with a Gmail/Workspace account."

Summary Table: Identifier Syntax

Identity Type	Identifier Prefix	Example
User	`user:`	`user:[email protected]`
Service Account	`serviceAccount:`	`serviceAccount:[email protected]`
Group	`group:`	`group:[email protected]`
Domain	`domain:`	`domain:example.com`
Federated Workload	`principal://`	`principal://iam.googleapis.com/.../subject/spiffe://...`
Federated Group	`principalSet://`	`principalSet://iam.googleapis.com/.../group/devs`
Public	(Special)	`allUsers`

Why so many?

The variety exists to support Least Privilege. In a legacy world, you'd just give everyone a Service Account Key. In a Zero Trust world, you use Workload Identity for your code, Workforce Identity for your employees, and Agent Identity for your AI—ensuring that every entity has a unique, short-lived, and verifiable "passport."

Google Cloud IAM

Google Cloud IAM (Identity and Access Management) follows a simple but powerful "Policy-based" model. To understand how it works, you have to look at the IAM Equation:

Who (Principal) + Can do what (Role) + On which resource (Resource) = The Policy

1. The Core Components

A. The Principal (The "Who")

As we discussed, this is the identity. It can be a person (user:[email protected]), a machine (serviceAccount:[email protected]...), or a federated identity (principal://...).

B. The Permission (The "Atomic Unit")

Permissions are the most granular level of access. They are usually formatted as service.resource.verb.

Example: storage.buckets.list or compute.instances.start.
Crucial Rule: You cannot assign a permission directly to a user. You must use a Role.

C. The Role (The "Bucket of Permissions")

A Role is a collection of one or more permissions.

Basic Roles: (Owner, Editor, Viewer). Avoid these; they are too broad.
Predefined Roles: Managed by Google (e.g., "Storage Object Viewer").
Custom Roles: You pick exactly which permissions you want.

2. The Resource Hierarchy (Where IAM lives)

This is the most important part of GCP's architecture. Permissions are inherited from the top down.

Organization: The root (your company).
Folders: To group projects (e.g., "Production" vs. "Development").
Projects: The main container for your resources.
Resources: The actual GCS Bucket, VM, or BigQuery Table.

The Inheritance Rule: If you are an "Editor" at the Folder level, you are automatically an "Editor" for every Project and every VM inside that folder. You cannot "un-inherit" a permission lower down.

3. The "Allow" Policy (Policy Binding)

An IAM Policy is a collection of bindings. A binding ties a Principal to a Role.

Example of a Policy Binding:

Role: roles/storage.objectViewer
Members: user:[email protected], group:[email protected]

This policy is then attached to a resource. If Bob tries to read a file, GCP checks the policy on the file, then the bucket, then the project, up to the Org.

4. IAM Conditions (The Zero Trust Layer)

Standard IAM is "always on." However, GCP supports IAM Conditions, which add logic to the binding. Access is only granted if the condition is true.

Time-based: "Allow Bob to be an Admin only between 9 AM and 5 PM."
Attribute-based: "Allow the Service Account to access the bucket only if the resource has the label env:dev."
Access Context Manager (CAA): "Allow access only if the user is on a corporate-managed device." (This is how Zero Trust is enforced).

5. The Evaluation Logic (How GCP decides)

When a request comes in (e.g., "Can I delete this VM?"), GCP’s IAM engine follows this logic:

Check Deny Policies: GCP first checks if there are any Deny Policies. If a Deny policy matches the user and the action, the request is blocked immediately. Deny always wins.
Collect Allow Policies: GCP gathers every "Allow" policy attached to the resource and every parent above it (Project -> Folder -> Org).
Check Conditions: For each "Allow" policy, GCP evaluates any attached conditions (Time, Device Health, IP).
The Decision: If at least one valid Allow policy exists (and no Deny policy exists), the request is permitted. Otherwise, it is denied by default.

6. Modern Evolution: Deny Policies

For years, GCP IAM was "Allow-only." Recently, Google added Deny Policies.

Why? In the past, if a user was an "Owner" at the Org level, you couldn't stop them from touching a specific sensitive project.
Now: You can create a Deny policy at the Org level that says: "No one, not even an Owner, can delete logs in the Audit Project."

Summary: Why this works for Zero Trust

GCP IAM is powerful because it is centralized. Because every single API call to any Google service must pass through this IAM evaluation engine, Google can enforce Zero Trust checks (like Device Health or Attestation) at the "gate" before the request ever reaches the data.

What is Workload Identity Federation?

Workload Identity Federation: workload running in AWS/Azure can access Google Cloud resources
- e.g. a VM running on AWS writes result to a GCS bucket.
Workload Identity Federation for GKE: workload running in GKE can access Google Cloud resources.
- Kubernetes service accounts (which is different from GCP service account) in the GKE cluster can access Google Cloud resources directly.