Google Cloud IAM Security Checklist for Beginners

A practical, prioritized checklist for hardening Google Cloud IAM. Score each item, focus on highest-impact first, re-score quarterly.

---

1. Hierarchy

• Folders used (at minimum Prod / NonProd / Sandbox).
• Project per workload / environment.
• Naming convention for folders / projects.
• Org-level bindings minimized.
• Folder owners documented.

2. Human Access

• Cloud Identity / Workspace as IdP (or federated).
• MFA enforced (hardware for admins).
• Group-based IAM bindings.
• No individual user bindings (outside specific cases).
• Workforce Identity Federation for external IdP users.

3. Privileged Access

• Standing Owners / Editors minimized.
• No Owner/Editor at Org level (except minimal break-glass).
• Token Creator scoped per specific SA.
• Service Account User scoped per specific SA.
• JIT admin via IAM Conditions where applicable.
• Approval workflow for sensitive impersonation.
• Quarterly access review on privileged roles.

4. Roles

• No basic roles in production.
• Predefined roles preferred.
• Custom roles in Terraform / version control.
• Custom roles peer-reviewed.
• Quarterly custom role review.
• IAM Recommender findings actioned.

5. Bindings

• No allUsers / allAuthenticatedUsers (outside intentional).
• No domain: broad bindings.
• Bindings at smallest scope.
• Conditions used for time / context.
• Deny policies for org-wide guardrails.

6. Service Accounts

• Per-workload SAs (not default).
• Default Compute SA Editor role removed.
• iam.automaticIamGrantsForDefaultServiceAccounts disabled at Org.
• All SAs tagged with owner / purpose.
• Quarterly stale SA cleanup.
• Cross-project SA usage documented.

7. Service Account Keys

• SA keys minimized; impersonation / federation preferred.
• iam.disableServiceAccountKeyCreation Org Policy where appropriate.
• iam.disableServiceAccountKeyUpload Org Policy.
• Existing keys inventoried, rotated, eliminated.
• Leaked-key monitoring (GitHub secret scanning).

8. Federation

• Workload Identity Federation in CI/CD (GitHub Actions, GitLab).
• Workload Identity for GKE workloads.
• WIF for AWS / Azure / on-premises workloads.
• Strict attribute conditions on every WIF provider.
• Workforce Identity Federation for external IdP users.
• Federation pool / provider documentation.

9. Org Policies

• Baseline Org Policies at Org root.
• iam.disableServiceAccountKeyCreation (where appropriate).
• iam.allowedPolicyMemberDomains.
• compute.requireOsLogin.
• compute.vmExternalIpAccess restricted.
• storage.publicAccessPrevention: enforced.
• Region restrictions.
• Folder-level refinements for prod.

10. Public Exposure

• No public Cloud Storage buckets (Public Access Prevention enforced).
• No public BigQuery datasets / tables.
• No public Pub/Sub topics.
• No public Cloud Functions / Cloud Run services unless intended (with auth).
• Cloud Asset Inventory queries to detect public bindings.

11. Logging

• Admin Activity audit logs always on.
• Data Access audit logs enabled for sensitive services.
• Aggregated log sink to dedicated logging project.
• Logging bucket immutable / long retention.
• Audit logs streamed to SIEM.

12. Detection

• Security Command Center enabled (Premium where possible).
• Detections live for:
  • New Owner / Editor binding.
  • New Token Creator.
  • New SA key.
  • New WIF provider.
  • Public binding (allUsers/allAuthenticatedUsers).
  • Unusual impersonation chains.
  • Unusual sign-ins (Workforce / Workspace).
• Findings triaged by SOC.

13. Response

• Incident playbooks for: SA compromise, public exposure, rogue admin, federation abuse.
• Tabletop exercises annually.
• Break-glass procedure documented and tested.

14. Governance

• All projects / folders documented and owned.
• Joiner / mover / leaver via group membership.
• Quarterly stale identity cleanup.
• Quarterly access review on privileged roles.
• Vendor offboarding removes federation / SA access.
• IAM bindings / Org Policies in Terraform; peer review.

15. Continuous Improvement

• Posture score tracked (Forestall, Security Command Center).
• Top risks reported to leadership quarterly.
• Continuous attack-path analysis.
• Best-practice metrics tracked (MFA adoption, SA key count, public bindings, etc.).

---

How to Use This Checklist

1. Score each item as Implemented / Partial / Not Started.
2. Identify the worst 5–10 in high-impact sections (Hierarchy, Privileged Access, SA Keys, Org Policies, Logging).
3. Make those this quarter's goals.
4. Re-score quarterly.
5. Use trend (items implemented over time) as your KPI.

---

How Forestall Helps

Forestall checks every project / folder against these and many more items, ranks findings by attack-path impact, and tracks remediation — turning this checklist into measurable Google Cloud IAM risk reduction over time.

---

Conclusion

Google Cloud IAM has many surfaces, but a small set of high-impact controls (folders, predefined roles, no basic roles in prod, Workload Identity Federation, default SA hardening, baseline Org Policies, centralized audit logs, identity-focused detections) closes most risk for most organizations. Use this checklist as your map; fix the highest-impact items first; and watch your GCP identity attack surface shrink quarter over quarter.