GCP IAM Misconfigurations Beginners Miss

Top 8 Google Cloud IAM Misconfigurations Beginners Miss

ByPouya Nourizadeh

Google Cloud Platform IAM is incredibly powerful and flexible, but that same adaptability is why beginners (and even experienced teams) accidentally create overly permissive setups, privilege escalation paths, or audit nightmares.

This updated 2025 guide corrects inaccuracies from prior versions and adds the latest real-world risks that caused breaches in 2024–2025.

Let’s lock it down properly.

1. Still Using Primitive Roles (Owner, Editor, Viewer)

Primitive roles sit at the top of the console UI and feel convenient, but they are almost never the right choice in 2025.

Why This Approach Fails
  • Viewer is frozen but still extremely broad (thousands of read permissions across nearly every legacy and many modern services).
  • Editor and Owner give near-unlimited control over the entire project.
  • Auditing and least-privilege enforcement become impossible.
Fix

Always prefer predefined roles (e.g., roles/storage.objectViewer, roles/bigquery.dataEditor) or custom roles.

Run regular audits:

gcloud projects get-iam-policy YOUR_PROJECT_ID --format="table(bindings.role, bindings.members)"

Turn on IAM Recommender and act on its suggestions (it now includes “Revoke unused access” recommendations).

2. Granting Permissions at Project Level Instead of Resource Level

Giving someone project-level access when they only need one bucket or dataset is the #1 cause of excessive blast radius.

Fix

Bind roles at the most granular level the hierarchy allows:

  • Cloud Storage bucket
  • Pub/Sub topic/subscription
  • Cloud Run / Cloud Functions service
  • Secret Manager secret
  • Individual Compute Engine instances (instance-level IAM)

The hierarchy:

Organization → Folder → Project → Resource

Higher-level grants should be rare and intentional.

3. Service Account Misuse & Impersonation Nightmares

Service accounts are machine identities, not user accounts.

Common deadly patterns in 2025
  • Giving service accounts Owner/Editor
  • Granting roles/iam.serviceAccountTokenCreator broadly
  • Granting roles/iam.workloadIdentityUser broadly ← this was the #1 escalation vector in 2024–2025 breaches
  • Still creating and rotating long-lived SA keys
Fixes
  • Grant only minimal predefined or custom roles to the SA itself.
  • Never create SA keys for Google-hosted runtimes (Cloud Run, GKE, Cloud Functions, Cloud Build) they use short-lived tokens by default.
  • For external/CI systems, use Workload Identity Federation (no keys).
  • If impersonation is required, grant roles/iam.serviceAccountTokenCreator or roles/iam.workloadIdentityUser only on the exact target service account(s), never at the folder/org level.

Check for forgotten keys:

gcloud iam service-accounts keys list --iam-account=sa-name@project.iam.gserviceaccount.com

4. Accidentally Public Buckets & Resources

Still one of the fastest ways to end up on a breach disclosure list.

Fix

Enable Uniform Bucket-Level Access:

gsutil uniformbucketlevelaccess set on gs://your-bucket

Search for dangerous bindings across the entire org:

gcloud asset search-all-iam-policies \
  --scope=organizations/ORG_ID \
  --query="policy:allUsers || policy:allAuthenticatedUsers"

5. Ignoring IAM Conditions

IAM Conditions let you add time, IP, or resource-name guardrails.

Good 2025 examples

Temporary access:

request.time < timestamp("2026-01-01T00:00:00Z")

Restrict to corporate IPs:

request.auth.remote_ip in ["203.0.113.0/24", "198.51.100.0/24"]

Warning: IP conditions do not work on BigQuery, Compute Engine SSH, or most database services.
Use VPC-SC or resource-level network policies instead.

6. Not Using Deny Policies & Organization Policy Constraints

Google Cloud has supported explicit Deny since GA in October 2021.

Deny policies override everything and provide hard guardrails:

  • Block creation of SA keys org-wide
  • Prevent public buckets
  • Stop users from granting Owner at the project level
Common must-have Organization Policy constraints (2025)
constraints/iam.disableServiceAccountKeyCreation            # no more keys
constraints/iam.allowedPolicyMemberDomains                 # only your domain(s)
constraints/storage.publicAccessPrevention                 # blocks allUsers/allAuthenticatedUsers
constraints/iam.automaticIamGrantsForDefaultServiceAccounts  # stops auto-grants

Test denies with Policy Simulator before applying.

7. Skipping Folders and Resource Hierarchy

Even with only 3 projects today, not using folders will hurt later.

Recommended structure
Organization
├── Folder: Production
├── Folder: Non-Production
│   ├── Folder: Development
│   └── Folder: Staging
└── Folder: Shared-Services

Apply IAM, Deny policies, and Org Policy constraints at the folder level.

8. Granting Meta-Roles That Are the New Owner

These roles are the hidden risks in 2025.

  • Block creation of SA keys org-wide
  • Prevent public buckets
  • Stop users from granting Owner at the project level

If granted at the folder or organization scope, the recipient can escalate to the Owner anywhere underneath.
Such high-privilege assignments must be handled with extreme caution due to their escalation risk.

Final 2025 Checklist (run monthly)

1. Primitive & meta-role overuse

Check for overuse of primitive roles (Owner, Editor, Project IAM Admin) in projects.

gcloud projects get-iam-policy $PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role:~^(roles/owner|roles/editor|roles/resourcemanager.projectIamAdmin)$"

2. Public resources org-wide

Identify IAM policies that make resources publicly accessible (allUsers or allAuthenticatedUsers).

gcloud asset search-all-iam-policies \
  --scope=organizations/$ORG_ID \
  --query="policy:allUsers || policy:allAuthenticatedUsers"

3. Dangerous impersonation roles org-wide

Look for risky roles like serviceAccountTokenCreator or workloadIdentityUser that allow impersonation.

gcloud organizations get-iam-policy $ORG_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role:~(serviceAccountTokenCreator|workloadIdentityUser)"

4. Unused / over-permissive access

Use Security Command Center recommendations to identify and remove unnecessary IAM permissions.

Go to Security Command Center → IAM Recommendations → Act on all

Fix these 8 areas and you’ll be ahead of 95% of Google Cloud deployments in 2025.

Pouya Nourizadeh - Cloudformix Author
Pouya Nourizadeh
About Author

Pouya Nourizadeh is the founder of Cloudformix, with extensive experience optimizing enterprise cloud environments across AWS, Azure, and Google Cloud. For years, he has addressed real-world challenges in cloud cost management, performance, and architecture, offering practical insights for engineering teams navigating modern cloud complexities.

Similar Posts