Common Google Cloud IAM Misconfigurations

GCP IAM is powerful — and easy to misuse. The same patterns appear across most audits and incidents. This article catalogs them with detection guidance and remediation.

---

1. Basic Roles in Production

Pattern: roles/owner, roles/editor, or roles/viewer granted at Project / Folder / Org level.

Risk: Wildly broad permissions across thousands of services.

Detection:

• Audit IAM bindings for basic roles.
• Especially: Org / Folder level bindings.

Remediation:

• Replace with service-scoped predefined or custom roles.
• IAM Recommender will suggest alternatives.

---

2. allUsers / allAuthenticatedUsers Bindings

Pattern: Bindings granting roles to public principals.

Risk: Public exposure of resources (GCS buckets, BigQuery datasets, Pub/Sub topics, etc.).

Detection:

• Audit bindings for allUsers / allAuthenticatedUsers.
• Cloud Asset Inventory queries.
• Org Policy iam.allowedPolicyMemberDomains to restrict.

Remediation:

• Remove public bindings.
• Use signed URLs / CDN with OAuth for legitimate public access.
• Set Org Policy to forbid public principals where possible.

---

3. Default Compute Service Account with Editor

Pattern: Project's default Compute Engine SA retains its initial Editor role.

Risk: Any compromised workload (GCE VM, GKE pod, Cloud Run service) can act as Editor on the project.

Detection:

• Identify SA email pattern <project-num>[email protected] and check its role bindings.

Remediation:

• Remove Editor; grant least-privilege roles.
• Use Org Policy iam.automaticIamGrantsForDefaultServiceAccounts to disable auto-grant on new projects.
• Replace default SAs with purpose-built ones per workload.

---

4. Service Account Keys

Pattern: SA keys (JSON) generated and distributed.

Risk: Keys leaked in code, CI configs, dev machines → credential breach.

Detection:

• List active keys per SA.
• Check key age.
• Org Policy iam.disableServiceAccountKeyCreation / iam.disableServiceAccountKeyUpload.

Remediation:

• Migrate to Workload Identity Federation, Service Account Impersonation, attached SAs.
• Rotate / revoke unused keys.
• Enforce Org Policy to block new key creation where possible.

---

5. Broad Token Creator / Service Account User

Pattern: roles/iam.serviceAccountTokenCreator or roles/iam.serviceAccountUser granted at Project or Org level.

Risk: Principal can impersonate any SA in scope; privilege escalation chains.

Detection:

• Audit bindings; alert on Project/Org-level grants of these roles.

Remediation:

• Grant per-specific-SA only.
• Document business need.

---

6. Org-Level Owner / Editor

Pattern: Owner or Editor granted at Org node.

Risk: Full reach across the entire organization.

Detection:

• Org IAM bindings list.

Remediation:

• Remove unless absolutely required (e.g., the founder); replace with scoped roles.
• Use folder/project bindings instead.

---

7. Domain-Wide Bindings

Pattern: domain:example.com granted broad roles (Editor, etc.).

Risk: Compromise of any employee account = wide reach.

Detection:

• Audit for domain: member references in bindings.

Remediation:

• Replace with group-based bindings on smaller groups.

---

8. Stale Principals

Pattern: Departed users, decommissioned vendors, unused SAs still in bindings.

Risk: Forgotten access surface; compromised credentials still authorized.

Detection:

• Cross-reference principal list with HR / vendor list.
• IAM Recommender unused-permission findings.

Remediation:

• Quarterly cleanup; lifecycle automation via groups.

---

9. Misconfigured Workload Identity Federation

Pattern: WIF provider trusts external IdP with weak / no attribute conditions.

Risk: Wrong external repos / accounts can authenticate.

Detection:

• Audit WIF provider attribute conditions.

Remediation:

• Apply strict attribute.repository, attribute.repository_owner, etc. conditions.

---

10. Custom Role Bloat

Pattern: Custom roles defined years ago, accreted permissions, now Editor-like.

Risk: Effective Editor in disguise; lost least-privilege intent.

Detection:

• Review custom role definitions periodically.
• Compare permissions count to similar predefined roles.

Remediation:

• Slim custom roles; split if covering multiple use cases.

---

11. No Use of Folders

Pattern: Flat structure — all projects directly under Org.

Risk: No environment / team separation; org-level bindings affect everything.

Detection:

• Check folder count vs project count.

Remediation:

• Introduce folders (Prod / NonProd / Sandbox at minimum).

---

12. No Org Policies

Pattern: Org Policies left at defaults.

Risk: No baseline guardrails; misconfigurations spread freely.

Detection:

• List Org Policies at Org level.

Remediation:

• Apply baseline Org Policies: disable SA key creation, restrict allowed regions, restrict allowed external IPs, require OS Login, etc.

---

13. No Cloud Audit Log Sinks

Pattern: Audit logs not centralized; default retention.

Risk: Blind to attacker activity; impossible to investigate.

Detection:

• Check log sinks at Org level.

Remediation:

• Aggregated sink to dedicated logging project; long retention; immutable bucket.

---

14. Missing Detection on IAM Events

Pattern: No alerts on IAM binding changes, key creation, role assignment.

Risk: Misuse goes unnoticed.

Detection:

• Check SIEM rules / Security Command Center configurations.

Remediation:

• Detection on: new Owner/Editor binding, new Token Creator, new SA key, new WIF provider, public binding (allUsers/allAuthenticatedUsers).

---

15. Cross-Project SA Sprawl

Pattern: Service accounts in project A bound to roles across many other projects without governance.

Risk: Hidden cross-project trust; opaque blast radius.

Detection:

• Cross-project IAM analysis (Forestall).

Remediation:

• Document cross-project SA usage; replace with project-local SAs where possible; impersonation patterns.

---

16. Public Cloud Storage Buckets

Pattern: Bucket-level IAM with allUsers/allAuthenticatedUsers or legacy public ACLs.

Risk: Data breach.

Detection:

• Cloud Storage Public Access Prevention; Cloud Asset Inventory.

Remediation:

• Enable Public Access Prevention at Org level.
• Tighten bucket policies.

---

17. Service Account Acting Beyond Its Scope

Pattern: SA for one workload bound to roles for another workload's resources.

Risk: Workload compromise extends to unrelated resources.

Detection:

• SA-to-resource graph; Forestall analysis.

Remediation:

• Per-workload SAs; tight bindings; clean separation.

---

How Forestall Helps

Forestall continuously checks for these (and many more) misconfiguration patterns across your GCP hierarchy, ranks findings by attack-path impact, and tracks remediation. Findings include affected principals, resources, and recommended fixes.

---

Conclusion

A small set of recurring patterns drives most Google Cloud IAM risk. Inventory, detect, and remediate them — basic roles, public bindings, default SA Editor, SA keys, broad Token Creator, missing folders, missing Org Policies, missing detections — and you'll close the bulk of your attack surface. Make detection continuous, not annual, and you'll stay ahead as your GCP environment evolves.