This article is based on a guide originally published on business2community.com and covers foundational Google Cloud IAM concepts relevant to any DevOps or cloud engineering team.
Why Google Cloud IAM Deserves Careful Thought
Google Cloud IAM (Identity and Access Management) is the core access-control layer for everything running on Google Cloud Platform. It enforces the principle of least privilege: every identity — human or machine — should have exactly the permissions it needs and nothing more.
As an organization scales, keeping IAM assignments accurate and auditable becomes increasingly difficult. A disciplined checklist helps teams avoid common mistakes: over-permissioning a service account, assigning project-wide roles when resource-level roles would suffice, or granting access to individuals instead of groups.
Every IAM assignment in Google Cloud answers exactly three questions. Thinking through them in order keeps your security posture tight and makes future audits straightforward.
Question 1: Who? (The Identity)
The first step is deciding which principal will receive the permission. Google Cloud IAM supports several identity types:
- Google Account — A single user identity (e.g.,
engineer@example.com). Used when a human needs direct access. - Service Account — A non-human identity intended for applications, scripts, or automated tools. Service accounts can have keys or can rely on Workload Identity Federation.
- Google Group — A collection of Google Accounts and service accounts managed through Google Groups. Grants access to everyone in the group, simplifying large-team management.
- Google Workspace (formerly G Suite) Domain — Grants access to all identities within a Workspace domain. Use with extreme caution given the breadth of the grant.
- allAuthenticatedUsers / allUsers — Special identifiers that grant access to anyone authenticated or anyone at all. These are almost always inappropriate for sensitive resources.
Recommendations for Identity Selection
- Start narrow, expand as needed. Assign access to the smallest practical set of identities. It is easier to grant additional access later than to revoke over-provisioned access after a breach.
- Prefer groups over individuals. Managing a Google Group is operationally simpler than updating dozens of individual IAM bindings when team membership changes.
- Use dedicated service accounts per workload. A single service account shared across multiple tools makes it impossible to know which tool triggered which API call. Separate accounts enable accurate audit logging and targeted revocation.
- Separate automated from human identities. Service accounts with narrow, well-documented purposes are much easier to review and rotate than user accounts used for both manual and automated tasks.
Question 2: What Access? (The Role)
Permissions in Google Cloud map directly to specific Google Cloud REST API methods. A permission name follows the pattern <service>.<resource>.<verb>. For example, compute.instances.start allows the caller to issue a start command to a Compute Engine instance.
Permissions are never granted individually. They are bundled into roles, and roles are what you assign to an identity. There are three role types:
1. Primitive (Basic) Roles
The three primitive roles — Owner, Editor, and Viewer — predate the current IAM system and bundle an enormous number of permissions across every GCP service. They should be avoided in production environments. Assigning Editor to a service account that only needs to read Cloud Storage objects is a classic over-permissioning mistake.
2. Predefined Roles
Google maintains a curated library of predefined roles scoped to individual services. For example:
roles/cloudsql.client— Includescloudsql.instances.connectandcloudsql.instances.get, allowing an application to connect to Cloud SQL without administrative rights.roles/storage.objectViewer— Allows reading objects in Cloud Storage without the ability to list buckets or write data.roles/container.developer— Allows deploying workloads to GKE without cluster administration privileges.
Predefined roles vary significantly in breadth. Always review the full list of included permissions before assigning one, especially roles with names like Admin or Developer.
3. Custom Roles
When no predefined role matches your requirements exactly, you can create a custom role that lists only the specific permissions your workload needs. This is the most precise way to implement least privilege. For example, a deployment tool that only needs to update Cloud Run services and read Secret Manager values can be given exactly run.services.update and secretmanager.versions.access — nothing else.
Recommendations for Role Selection
- Never use primitive roles in production unless you have a specific, documented reason.
- Use predefined roles as a starting point. They are well-maintained and align with common access patterns.
- Use custom roles for automated workloads. Scripting and tools have predictable, bounded API usage — document and enumerate the exact permissions they need, then build a custom role from that list.
- Review included permissions before assigning any role. Use the GCP Console or
gcloud iam roles describe <role>to see the full permission list.
# Inspect a predefined role before assigning it
gcloud iam roles describe roles/cloudsql.client
# List permissions in a custom role
gcloud iam roles describe my-custom-role --project=my-projectCode language: PHP (php)Question 3: Which Resource? (The Resource Scope)
After choosing an identity and a role, you attach the IAM policy to a specific resource. The resource determines the scope of the permission. Google Cloud’s resource hierarchy runs from broad to narrow:
- Organization — The root of the hierarchy. Policies here apply to everything under the organization.
- Folder — A grouping of projects, useful for department- or environment-level boundaries.
- Project — The most common attachment point. Policies set at the project level apply to all resources within the project.
- Individual resources — Many resource types (Cloud Storage buckets, Compute Engine instances, Pub/Sub topics, BigQuery datasets, etc.) support IAM policies set directly on the resource.
Each predefined role specifies the lowest resource level at which it can be granted. For example, App Engine Admin must be granted at the project level, while Storage Object Viewer can be granted on a single bucket. You can always attach a role at a higher level than the minimum, but broader attachments mean broader access.
Policies are also inherited down the hierarchy. A role granted at the organization level is effective at the project and resource levels. This makes organization- and folder-level grants powerful — and risky if misapplied.
Recommendations for Resource Scoping
- Apply the policy at the lowest appropriate level. If a service account only needs to read a single Cloud Storage bucket, bind the role to that bucket, not to the entire project.
- Use projects to group related resources. Creating a dedicated project for a specific service or environment makes it practical to assign project-level roles without accidentally exposing unrelated resources.
- Be explicit about inheritance. Document any roles granted at the folder or organization level and audit them regularly, since they affect all descendant resources.
- Audit policies with Policy Analyzer. Google Cloud’s Policy Analyzer tool can help you understand who has access to what across your resource hierarchy.
Putting It All Together: A Pre-Assignment Checklist
Before making any IAM change, run through these three questions:
| Question | What to decide | Least-privilege default |
|---|---|---|
| Who? | Google Account, Service Account, Group, or Domain | Smallest identity scope; prefer a dedicated service account for automation |
| What access? | Primitive, Predefined, or Custom Role | Custom or narrowest predefined role; never use primitive roles in production |
| Which resource? | Organization, Folder, Project, or individual resource | Lowest level in the hierarchy that satisfies the requirement |
Ongoing IAM Hygiene
Answering these three questions correctly at the time of provisioning is only the start. IAM hygiene requires continuous effort:
- Review IAM bindings regularly. Team membership changes, projects evolve, and tools get replaced. Stale permissions accumulate silently.
- Enable and review Cloud Audit Logs. Data Access logs capture who called which API on which resource. They are invaluable for detecting unexpected access patterns.
- Use IAM Recommender. Google Cloud’s built-in recommender analyses actual API usage and suggests removing permissions that have not been used within a rolling window.
- Automate policy enforcement with policy-as-code tools. Terraform, Config Connector, or Organization Policy constraints can codify your IAM standards and prevent drift.
Summary
Every Google Cloud IAM assignment reduces to three decisions: the identity receiving access, the role defining what that access covers, and the resource the policy is bound to. Getting all three right — and defaulting to the narrowest option in each case — is how teams implement least privilege in practice rather than just in principle.