Google Cloud IAM Security Best Practices

A consolidated list of Google Cloud IAM security best practices, drawn from Google's official guidance, the CIS Google Cloud Benchmark, and patterns observed in real incident response.

---

1. Hierarchy Foundation

• Use folders — at minimum Prod / NonProd / Sandbox.
• Project per workload / environment — small, purpose-driven projects.
• Naming conventions — consistent across folders / projects.
• Bindings at smallest scope — resource > project > folder > org.
• Document folder ownership.

2. Identity Plane

Human Access

• Cloud Identity / Workspace as IdP (or federated to external IdP via Workforce Identity Federation).
• Group-based bindings (not individuals).
• MFA enforced (hardware preferred for admins).
• Quarterly access review on privileged roles.

Workload Access

• Workload Identity Federation for external workloads (GitHub Actions, AWS, Azure, on-premises).
• Attached service accounts for GCE/GKE/Cloud Run/Cloud Functions.
• Workload Identity for GKE (per-workload SAs).

Service Accounts

• One SA per workload with specific roles.
• No default Compute SA with Editor.
• No long-lived SA keys; impersonation / federation instead.
• SA owners tagged.
• Quarterly stale SA cleanup.

Long-Lived Credentials

• Disable SA key creation via Org Policy where possible.
• Audit existing keys; rotate / eliminate.
• Monitor for leaked keys (GitHub secret scanning, GitGuardian).

---

3. Authorization

Roles

• Avoid basic roles in production.
• Predefined roles preferred; custom when needed.
• Custom roles in IaC (Terraform); peer-reviewed.
• Quarterly custom role review.
• IAM Recommender findings actioned.

Bindings

• No allUsers/allAuthenticatedUsers outside intentional public.
• No domain-wide broad bindings.
• Scope bindings tightly.
• Use IAM Conditions for context.
• Use Deny policies for org-wide guardrails.

Privileged Access

• Standing admins minimized.
• JIT admin via IAM Conditions (time-bound).
• Approval workflow for sensitive impersonation.
• Token Creator scoped per specific SA.

---

4. Org Policies

• Apply baseline at Org root:
  • iam.disableServiceAccountKeyCreation (consider).
  • iam.disableServiceAccountKeyUpload.
  • iam.allowedPolicyMemberDomains to restrict allowed principal domains.
  • iam.automaticIamGrantsForDefaultServiceAccounts: false.
  • compute.requireOsLogin.
  • compute.vmExternalIpAccess restricted.
  • Region restrictions where applicable.
  • storage.publicAccessPrevention: enforced.
• Refine at folder level for production stricter than non-prod.
• Test in non-prod before enforcing.

5. Federation

Workforce Identity Federation

• External IdP for workforce (Entra ID, Okta).
• Group / role mapping documented.
• MFA at IdP.

Workload Identity Federation

• GitHub Actions, GitLab, AWS, Azure, on-premises k8s.
• Strict attribute conditions on every provider.
• Per-pool, per-provider documentation.

---

6. Logging and Monitoring

Cloud Audit Logs

• Admin Activity always on.
• Data Access logs enabled for sensitive services.
• Aggregated sink to dedicated logging project.
• Long retention (≥ 1 year).
• Immutable bucket / archive class.

SIEM Integration

• Audit logs streamed to SIEM (Chronicle, Splunk, Sentinel).
• Identity-specific detections:
  • New Owner/Editor binding.
  • New Token Creator.
  • New SA key.
  • New WIF provider.
  • Public binding (allUsers/allAuthenticatedUsers).
  • Unusual impersonation chains.
  • Unusual sign-ins.

Security Command Center

• Premium tier where possible.
• Findings triaged.
• Risk-based prioritization (Forestall integration where applicable).

7. Detection and Response

Playbooks

• Compromised SA key.
• Compromised user account.
• Public bucket / dataset exposure.
• Rogue admin.
• Federation provider abuse.

Tabletop Exercises

• Annually.
• Cross-functional (Security, IT, Eng, Legal).

Incident Response

• SOAR integration where possible.
• Defined SLAs for critical identity findings.

8. Governance

Inventory

• All projects known and owned.
• All folders documented.
• All SAs tagged with owner / purpose.
• Cross-project SA usage documented.

Lifecycle

• Joiner / mover / leaver via group membership.
• Quarterly cleanup of inactive identities.
• Vendor offboarding removes federation / SA access.

Access Reviews

• Quarterly on privileged roles + Token Creator.
• Annual on broader.
• Auto-remove on no-action.

Policy as Code

• IAM bindings, custom roles, Org Policies in Git (Terraform).
• Peer review.
• Drift detection.

9. Recovery

• Break-glass account documented (rare; per Google guidance).
• Hardware MFA for break-glass stored in safe.
• Tested periodically.
• Backup of critical configurations (IAM, Org Policies) tracked in IaC.

10. Continuous Improvement

• Track metrics:
  • Number of standing privileged bindings.
  • Number of SA keys.
  • Number of SAs without owner.
  • Public bindings count.
  • IAM Recommender open findings.
  • MFA adoption.
• Quarterly identity review to leadership.
• Posture tool (Forestall) for continuous attack-path analysis.
• Trend as KPI.

---

Quick Best-Practice Summary

• Folders for environment / team separation.
• Project per workload / env.
• Predefined / custom roles, never basic in prod.
• Group-based bindings.
• Workload Identity Federation in CI/CD.
• SA impersonation instead of keys.
• Default SAs tamed; per-workload SAs.
• Org Policies as baseline guardrails.
• IAM Conditions for time / context.
• Deny policies for org-wide guardrails.
• Cloud Audit Logs centralized + identity detections.
• Quarterly access reviews.
• Continuous attack-path analysis.

---

How Forestall Helps

Forestall translates these best practices into continuous, prioritized work across your Google Cloud:

• Posture scoring against best practices.
• Attack-path analysis to admin and data.
• Risk-ranked findings with remediation.
• Trend tracking for identity security KPIs.

---

Conclusion

Google Cloud IAM security is a discipline, not a feature. Implement these best practices in tiers — start with hierarchy + predefined roles + Workload Identity Federation + baseline Org Policies + centralized audit logs — and expand outward. Measure quarterly. With these in place, GCP becomes one of the most defensible cloud identity environments you operate.