Least Privilege in GCP Explained for Beginners

What is least privilege?

Least privilege means giving an identity (a user, a service account, or a group) only the permissions it actually needs to do its job, on only the resources it actually touches, for only as long as it needs them.

In GCP, this plays out through IAM. Every time you grant a role, you are deciding two things: what actions are allowed, and where those actions apply. Least privilege is about keeping both of those as narrow as possible.

This page walks through what least privilege means in concrete GCP terms, how to apply it to common workloads, what makes it easy to get wrong, and how to review your access grants over time.

Simple explanation

Before diving into the GCP mechanics, here is the core idea in plain terms.

That is exactly what least privilege does in GCP. Instead of giving a service account a project-level roles/editor role (the master keycard), you give it roles/storage.objectCreator on one specific bucket (the loading dock key). If that service account is ever compromised, the attacker can only create objects in that one bucket. Everything else is out of reach.

How least privilege works in GCP

Applying least privilege in GCP means addressing two independent dimensions. Most teams address one and leave the other wide open.

Dimension 1: Role scope (which actions are allowed)

The IAM role you grant determines which API actions the identity can perform. Roles range from very broad (like roles/editor, which covers almost every service) to very narrow (like roles/storage.objectCreator, which only allows uploading objects to Cloud Storage).

Always start from the narrowest predefined role that covers the actual task. If no predefined role fits cleanly, consider a custom role.

Dimension 2: Resource scope (where those actions apply)

Even a narrow role grants access to all matching resources within the scope you bind it at. roles/storage.objectViewer at the project level gives read access to every bucket in the project. The same role bound to a specific bucket restricts it to that one bucket only.

GCP supports IAM bindings at four levels of the resource hierarchy:

• Organisation: applies to all folders, projects, and resources underneath
• Folder: applies to all projects in the folder
• Project: applies to all resources in the project
• Individual resource: applies only to that one resource (supported by Cloud Storage, BigQuery, Pub/Sub, Secret Manager, and others)

The lowest level that works for the workload is almost always the right choice. Project-level bindings are convenient but expose far more than intended.

Optional third dimension: conditions

IAM Conditions let you layer time and context restrictions on top of role and resource scope. You can grant a role that only applies during business hours, before a specific expiry date, or only to resources whose names match a given prefix. This is especially useful for temporary access during troubleshooting or incident response.

When to use least privilege

Least privilege is not just for large production environments. It applies any time an identity needs access to a GCP resource. Here are the most common situations:

• Service accounts running workloads. Every Cloud Run service, Cloud Function, or Compute VM should run as a dedicated service account with only the permissions that specific workload needs. Never use the default Compute Engine service account without reviewing and narrowing its access first.

• CI/CD pipelines deploying to GCP. A pipeline deploying to Cloud Run needs deploy permissions, not editor access across the project. Bind the deploy role to the specific Cloud Run service, not the whole project.

• Cloud Storage access. If an app uploads files, it needs roles/storage.objectCreator on that bucket, not roles/storage.admin on all buckets.

• Cloud SQL connections. An application reading from a database should have roles/cloudsql.client on the specific instance, not editor on the project.

• Human admin access. Engineers should be granted scoped roles for the resources they actively work on. Avoid assigning roles/owner to human users. Use more specific admin roles instead.

• Temporary troubleshooting access. When someone needs elevated permissions to investigate an incident, use IAM Conditions to set a time-based expiry. Temporary access that is never revoked becomes permanent risk.

Practical examples

Cloud Storage: upload service

# Wrong: project-level editor grants write access to every GCP service
gcloud projects add-iam-policy-binding my-app-prod \
  --member="serviceAccount:upload-svc@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/editor"

# Right: narrow role scoped to the one bucket this service actually uses
gcloud storage buckets add-iam-policy-binding gs://my-app-prod-uploads \
  --member="serviceAccount:upload-svc@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/storage.objectCreator"
# objectCreator allows: create objects, list objects
# It does NOT allow: read existing objects, delete objects, or access any other service

The better approach limits an incident to one bucket. The wrong approach exposes every service in the project.

Cloud Run: deployment pipeline

# Wrong: editor on the project gives the pipeline write access to every resource
gcloud projects add-iam-policy-binding my-app-prod \
  --member="serviceAccount:ci-deployer@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/editor"

# Right: deploy role scoped to the specific Cloud Run service
gcloud run services add-iam-policy-binding my-api \
  --region=us-central1 \
  --member="serviceAccount:ci-deployer@my-app-prod.iam.gserviceaccount.com" \
  --role="roles/run.developer"

roles/run.developer lets the pipeline deploy new revisions. It cannot touch Cloud Storage, BigQuery, or any other service in the project.

Cloud SQL: application database access

An application that connects to a Cloud SQL instance should have roles/cloudsql.client on that specific instance, not roles/cloudsql.admin or roles/editor on the project. The client role allows connecting and running queries. It does not allow creating or deleting instances, modifying configuration, or accessing other databases.

Logging and monitoring: read-only access

A user who needs to read logs for debugging should have roles/logging.viewer, not roles/viewer. roles/viewer grants read access to almost every service in the project, including configuration data and stored data that the person has no reason to see.

Least privilege vs broad access

The most common mistake is reaching for basic roles (roles/viewer, roles/editor, roles/owner) because they are simple to apply. They are also much more powerful than almost any workload actually needs.

Here is how the approaches compare:

For production workloads, the goal is to reach the third or fourth row. Project-level basic roles are acceptable for development exploration but should not exist in production IAM policies.

See

for a full breakdown of what each category includes and when to use each.

The over-privileged defaults you need to fix

GCP creates two default service accounts in every new project. Both have roles/editor granted by default, which is one of the most common high-severity findings in GCP security reviews:

• The Compute Engine default service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) gets roles/editor automatically. Any VM created without specifying a service account runs as this identity.

• The App Engine default service account (PROJECT_ID@appspot.gserviceaccount.com) also gets roles/editor by default.

How to apply least privilege safely

Follow this process whenever you need to grant access to a GCP resource:

1. Identify the task. What exactly does this identity need to do? Be specific: “read objects from a bucket” is better than “access storage.”

2. Identify the exact resource. Which specific resource does it need access to? A specific bucket, a specific Cloud SQL instance, a specific Cloud Run service.

3. Choose the narrowest role. Find the predefined role that covers the task without adding extra permissions. If nothing fits, consider a custom role. Check gcloud IAM commands or the Console to search available roles.

4. Bind at the lowest sensible scope. Grant at the individual resource level where possible. Only move to project or folder level if the workload genuinely needs access to all resources of that type within that scope.

5. Test with Policy Simulator before applying if in doubt. Policy Simulator lets you verify what a proposed IAM binding would allow or deny before it takes effect. Use it when reducing an existing role to confirm the narrower role still covers required operations.

6. Set an expiry if access is temporary. Use IAM Conditions to add a time-based expiry for access that should not be permanent.

7. Review later with IAM Recommender. After 90 days of activity, IAM Recommender will have enough data to tell you whether the role you granted is still too broad. Check it on a quarterly schedule.

If you manage IAM through code rather than the Console, see

for how to express these bindings declaratively.

Org-level guardrails that go beyond IAM

IAM controls what individual identities can do. For organisation-wide constraints that apply regardless of individual role assignments, use Organisation Policies. For example, iam.disableServiceAccountKeyCreation prevents key file creation across all projects, even if an admin at the project level tries to allow it. These structural controls complement least-privilege IAM by removing whole categories of risk at the platform level.

For service accounts specifically, avoid creating or distributing long-lived keys where possible. See

and

for safer alternatives.

Keeping permissions minimal over time

Permissions accumulate. People join teams, get temporary access, and that access is never revoked. Service accounts gather bindings as requirements change. IAM policies that were correct six months ago are often wrong today.

Two tools help keep things clean:

• IAM Recommender: analyses the last 90 days of API call history and recommends removing roles that have not been used. Available in the IAM section of the Console and via the API.

• Policy Simulator: lets you test what a proposed IAM change would allow or deny before applying it. Verify a narrower role still covers required operations before switching.