What is Google Cloud IAM?

Definition

Google Cloud Identity and Access Management (IAM) is the service that controls who (principal) can do what (permission) on which Google Cloud resource. Every Google Cloud API call is authorized by IAM evaluation against policy bindings that grant roles to principals at specific points in the resource hierarchy.

In simple terms:

Google Cloud IAM is GCP's policy engine: principals get roles on resources via bindings, and IAM evaluates those bindings on every API call.

---

Why Google Cloud IAM Matters

• Authorizes nearly every Google Cloud API call.
• Misconfiguration here is a top cause of GCP data exposure.
• Inheritance through the resource hierarchy means a single high-level binding can affect thousands of resources.
• Service accounts (with their impersonation patterns) are powerful and easily abused.

---

Core Concepts

Principals (Members)

The "who":

• Google Account (user:[email protected]) — individual user.
• Google Group (group:[email protected]) — group of users.
• Service Account (serviceAccount:[email protected]) — non-human identity.
• Cloud Identity / Workspace domain (domain:example.com) — entire domain.
• Workforce / Workload identity pools — federated identities.
• All authenticated users (allAuthenticatedUsers) — any authenticated Google account.
• All users (allUsers) — public, including unauthenticated.

Resources

Anything in Google Cloud: Compute Engine VMs, Cloud Storage buckets, BigQuery datasets, Cloud SQL databases, projects, folders, the Organization itself, etc.

Permissions

Atomic actions, formatted service.resource.verb:

• storage.objects.get
• compute.instances.start
• iam.serviceAccounts.actAs

Roles

Named collections of permissions:

• Basic roles (legacy): Owner, Editor, Viewer.
• Predefined roles: thousands of them, scoped per service (roles/storage.objectViewer).
• Custom roles: org/project-defined collections of permissions.

Policy Bindings

(role, principal[, condition]) triples attached to a resource. The combination of all applicable bindings determines effective permissions.

Resource Hierarchy

• Organization → Folders → Projects → Resources.
• IAM bindings inherit downward.

---

How an IAM Decision Works

1. Principal makes API request.
2. Google Cloud collects all IAM policies relevant to the resource (resource itself + ancestor folders + project + org).
3. Aggregated bindings define principal's permissions on that resource.
4. IAM Conditions (if present) narrow bindings by attribute (time, request, resource).
5. Deny policies (newer feature) explicitly exclude permissions.
6. If the requested permission is granted, allow; else deny.

Note: There is no automatic priority of "Allow" or "Deny" by resource level — Deny policies (when used) always win.

---

Common Risks

• Basic roles in production (Owner, Editor) — far too broad.
• allUsers / allAuthenticatedUsers bindings — public exposure.
• Owner at Organization level — full reach.
• Service Account Token Creator misuse — impersonation chain to higher privilege.
• Service accounts with overly broad roles.
• iam.serviceAccountUser misuse — pass service account to compute resources.
• Over-broad project-level bindings affecting all resources in the project.
• No use of folders for environment separation.
• Default service accounts (Compute Engine default SA) with Editor role.
• Service account keys stored long-term.
• Cross-project / cross-org bindings via federation poorly governed.

---

Real-World Examples

1. Public BigQuery Dataset

A data engineer added allUsers as Viewer on a BigQuery dataset for a "demo." Sensitive PII queryable publicly.

2. Default Compute Service Account with Editor

A misconfigured GKE workload uses the project default SA (Editor by default). A pod compromise gives the attacker Editor on the entire project.

3. Service Account Impersonation Chain

User has roles/iam.serviceAccountTokenCreator on a service account that has roles/owner. User impersonates → Owner on project. Privilege escalation in one step.

4. Org Admin Misuse

A new SRE was granted roles/owner at Organization level for "convenience." Compromise of their account = full org compromise.

---

Best Practices (Highlights)

1. Avoid basic roles in production; use predefined or custom.
2. Least privilege at the lowest possible level (resource > project > folder > org).
3. No allUsers / allAuthenticatedUsers unless intentional public.
4. Use folders to separate environments and apply scoped policies.
5. Tame default service accounts (disable, restrict, replace).
6. Workload Identity Federation instead of long-lived service account keys.
7. Service account impersonation (with audit) instead of distributing keys.
8. IAM Conditions for context-based restriction.
9. Deny policies for org-wide guardrails (org policy + IAM Deny).
10. Cloud Audit Logs for IAM events; centralize and alert.
11. Recommender (IAM Recommender) for least-privilege suggestions.
12. Continuous attack-path analysis.

---

How Forestall Helps

Forestall connects to Google Cloud and analyzes:

• Effective permissions per principal across the hierarchy.
• Service account impersonation chains.
• Public exposure (allUsers/allAuthenticatedUsers).
• Privilege escalation paths via dangerous IAM permissions.
• Risk-ranked findings tied to remediation guidance.

---

Frequently Asked Questions

Is Google Cloud IAM the same as AWS IAM?

Conceptually similar (principals, permissions, roles), but model differs: GCP uses inherited policies on a hierarchy and binding-based grants; AWS uses identity vs resource policies and JSON documents.

Are basic roles deprecated?

Not deprecated, but strongly discouraged. Use predefined / custom for any meaningful least privilege.

Can I have organization-level IAM?

Yes — at Org and Folder levels. These bindings inherit to all descendants.

What's the difference between roles and permissions?

Permissions are atomic (e.g., storage.objects.get). Roles are collections of permissions (e.g., roles/storage.objectViewer includes many storage permissions).

What's a Deny policy?

A newer feature that explicitly denies specific principals from specific permissions, regardless of allow bindings. Useful for organization-wide guardrails.

---

Conclusion

Google Cloud IAM is the heart of GCP security, and its hierarchy + binding model rewards careful design. Avoid basic roles, scope bindings tightly, govern service accounts and impersonation, eliminate long-lived keys via Workload Identity Federation, and use Audit Logs + posture analysis continuously. Done well, it's a flexible, auditable access plane; done poorly, it becomes the silent path attackers walk to your data.