GCP 403 PERMISSION_DENIED: Fix IAM, API, and Org Policy Errors

What “permission denied” means in plain English

Think of GCP like a building with a security desk. When you walk in, the guard checks three things: your ID badge (your identity), the room you want to enter (the resource), and the access list for that room (IAM permissions). A 403 PERMISSION_DENIED means the guard recognised your badge but your name is not on the list for that room.

In GCP terms, every API call involves four things: an identity (who is calling), a permission (what action they want), a resource (which thing they want to act on), and a scope (where the access grant exists in the resource hierarchy). A 403 means GCP checked these four things and found a gap.

If you are new to how GCP decides who can do what, read What Is IAM in GCP first. IAM is the system that maps identities to permissions on resources. Every permission denied error traces back to something in that mapping being wrong or missing.

Quick diagnosis checklist

Work through this checklist in order. Most permission denied errors resolve at step 1, 2, or 3.

1. Read the full error message. Extract the caller identity, the missing permission, and the target resource. Do not skip this step.
2. Identify the caller. Is it your user account, a service account, or a compute default service account? Run gcloud auth list or check the service account attached to your Cloud Run, GKE, or Cloud Functions workload.
3. Identify the missing permission. The error tells you the exact permission string (for example, storage.objects.get). Look up which predefined role includes that permission.
4. Check the resource scope. Confirm the IAM binding exists at the correct level: resource, project, folder, or organisation. A role granted at the wrong scope will not cover the target resource.
5. Confirm the API is enabled. Run gcloud services list —enabled and check for the relevant API. A disabled API returns a 403 that looks identical to a permission error.
6. Check org policy constraints. If IAM looks correct and the API is enabled, ask your organisation admin whether a constraint is blocking the action.
7. Retry after propagation delay. IAM changes take up to 60 seconds to propagate. If you just granted the role, wait a minute and retry.
8. Validate with testIamPermissions. Use the testIamPermissions API or Cloud Audit Logs to confirm whether the permission is actually granted.

How GCP evaluates permissions

Understanding the evaluation flow helps you pinpoint where the failure occurs. Think of it as a series of locked doors. The request must pass through every door in sequence, and a failure at any door produces a 403.

1. Who is calling? GCP extracts the identity from the request credentials. This could be a user account or a service account. If no valid credential is present, the request fails with UNAUTHENTICATED (401), not PERMISSION_DENIED (403).
2. Is the API enabled? If the API is not enabled in the target project, the request fails with a 403 that says SERVICE_DISABLED. This happens before IAM is even checked.
3. What permission is required? Each API method maps to one or more IAM permissions. For example, reading a Cloud Storage object requires storage.objects.get.
4. Which resource is targeted? The permission is checked against the specific resource in the request, not just the project.
5. Does an IAM binding exist? GCP walks up the resource hierarchy (resource, project, folder, organisation) looking for a binding that grants the required permission to the caller. If it finds one, the permission check passes. If not, it returns PERMISSION_DENIED. Learn how this hierarchy works in the IAM policies guide.
6. Does an org policy block the action? Even after IAM allows the request, organisation policy constraints can still deny it. Org policies override IAM.
7. Has the binding propagated? IAM is eventually consistent. A newly added binding may not be visible at every regional endpoint for up to 60 seconds.

What the error message tells you

Before touching IAM, read the full error. GCP error messages contain everything you need to act:

Error 403: The caller does not have permission, or the resource may not exist.
Permission 'storage.objects.get' denied on resource
'//storage.googleapis.com/projects/_/buckets/my-bucket/objects/config.json'
for caller 'backend-sa@my-project.iam.gserviceaccount.com'.

Extract three pieces of information:

• The permission: storage.objects.get, which is the exact IAM permission that is missing
• The resource: a specific object in a specific bucket
• The caller: the service account that made the call

With these three you know exactly what predefined role to grant, to which identity, and at which scope. You do not need to guess.

Root causes in order of frequency

1. Wrong identity making the call

The single most common cause. You grant a role to your personal account, but the code runs as a service account. Or you grant it to the right service account but in the wrong project. Always confirm the calling identity before making any IAM change.

Picture this: you hand a VIP pass to your friend, but your colleague is the one trying to enter the event. It does not matter how good the pass is if the wrong person is holding it.

Symptom: The error message shows a different caller than expected.

How to verify:

# Check which account gcloud is currently using
gcloud auth list

# Check the active project
gcloud config get-value project

# Find the service account a Cloud Run service runs as
gcloud run services describe SERVICE_NAME \
  --region=REGION \
  --format="value(spec.template.spec.serviceAccountName)"

# Find the service account a Cloud Function runs as
gcloud functions describe FUNCTION_NAME \
  --region=REGION \
  --format="value(serviceConfig.serviceAccountEmail)"

# Find the service account a GKE pod uses
kubectl get pod POD_NAME -o jsonpath='{.spec.serviceAccountName}'

Fix: Grant the role to the identity shown in the error message, not the identity you assumed was making the call. If the wrong identity is being used, fix the configuration at the source and attach the correct service account to the workload.

2. Role missing or granted at the wrong scope

Granting roles/storage.objectViewer at project level gives access to all buckets in the project. Granting it at bucket level gives access only to that bucket. If your error references a specific resource, make sure the grant covers that scope.

Symptom: The caller is correct and has a role, but the role does not include the required permission, or it is granted at a scope that does not cover the target resource.

How to verify:

# List all roles an identity has on the project
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:backend-sa@my-project.iam.gserviceaccount.com" \
  --format="table(bindings.role)"

# Check roles on a specific bucket
gcloud storage buckets get-iam-policy gs://my-bucket \
  --format="table(bindings.role, bindings.members)"

Fix: Use gcloud IAM commands to grant the correct predefined role at the narrowest scope that covers the target resource. Follow the principle of least privilege and grant access at the resource level, not the project level, when possible.

3. API not enabled

Symptom: The error includes a mention of SERVICE_DISABLED, or you recently started using a new GCP service in this project.

How to verify:

# Check if a specific API is enabled
gcloud services list --enabled --filter="name:sqladmin.googleapis.com"

Fix: Enable the API: gcloud services enable sqladmin.googleapis.com. For a deeper walkthrough, see API not enabled errors. You can also learn how to enable APIs via Console, gcloud, or Terraform.

4. Organisation policy blocking the action

Organisation policies sit above IAM. A constraint can block an action even when the IAM binding is correct. Common culprits:

• constraints/iam.allowedPolicyMemberDomains prevents adding accounts from external domains
• constraints/gcp.resourceLocations restricts which regions resources can be created in
• constraints/iam.disableServiceAccountKeyCreation blocks service account key creation

Symptom: IAM bindings are correct, the API is enabled, but the action still fails. The error may reference an org constraint directly.

How to verify:

# List effective org policies on a project
gcloud resource-manager org-policies list --project=PROJECT_ID

# Get the effective value of a specific constraint
gcloud resource-manager org-policies describe \
  constraints/iam.allowedPolicyMemberDomains --project=PROJECT_ID

5. IAM propagation delay

GCP IAM changes are eventually consistent. After you add a binding, it can take up to 60 seconds to propagate to all GCP regions.

Symptom: You just granted the role (within the last minute) and the error appeared immediately after.

Fix: Wait 60 seconds and retry. If the error persists after waiting, the cause is not propagation delay. Go back to step 1 of the checklist.

6. Cross-project resource access

When a service account in Project A needs to access a resource in Project B, the IAM binding must exist in Project B, not Project A. This is a common source of confusion because the service account lives in one project but the permission must be granted in the other.

Symptom: The service account has the right role in its home project, but the target resource is in a different project.

How to verify: Check the resource path in the error message. If it references a different project, check IAM bindings in that project.

# Grant a role to a cross-project service account
gcloud projects add-iam-policy-binding TARGET_PROJECT_ID \
  --member="serviceAccount:backend-sa@source-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Fix: Grant the role in the project (or on the resource) where the target resource lives, not in the service account’s home project.

7. Service account impersonation or workload identity mismatch

If you use service account impersonation or Workload Identity Federation, there are two layers of permissions. The caller needs permission to impersonate the target service account, and the target service account needs the actual resource permission.

Symptom: The error shows the impersonating identity lacks iam.serviceAccounts.actAs or iam.serviceAccounts.getAccessToken, or the target service account appears as the caller but lacks the resource permission.

How to verify:

# Check if the caller can impersonate the target service account
gcloud iam service-accounts get-iam-policy \
  target-sa@my-project.iam.gserviceaccount.com \
  --format="table(bindings.role, bindings.members)"

Fix: Grant roles/iam.serviceAccountTokenCreator on the target service account to the impersonating identity. Then separately ensure the target service account has the required resource permission.

Service-specific examples

The root cause is always the same (identity, permission, resource, scope), but the specific permission names and patterns vary by service. Here are the most common cases.

Cloud Storage

• Common symptom: storage.objects.get or storage.objects.create denied on a bucket or object
• Check first: Is the bucket using uniform bucket-level access or fine-grained ACLs? Uniform access ignores ACLs entirely. See Cloud Storage access denied errors for details.
• Likely fix: Grant roles/storage.objectViewer (read) or roles/storage.objectAdmin (read/write) at the bucket level to the correct service account

Cloud Run

• Common symptom: The Cloud Run service returns 403 when calling another GCP API (for example, reading from a bucket or publishing to Pub/Sub)
• Check first: What service account is the Cloud Run revision using? The default Compute Engine service account has broad permissions, but a custom service account may not.
• Likely fix: Attach a dedicated service account to the Cloud Run service and grant it only the specific roles it needs

Cloud Functions

• Common symptom: Function invocation fails with 403, or the function cannot access a downstream resource
• Check first: Cloud Functions v2 uses the default Compute Engine service account unless you specify one. Check which service account is attached.
• Likely fix: Assign a dedicated service account with the required roles. For invocation, grant roles/cloudfunctions.invoker to the calling identity.

BigQuery

• Common symptom: bigquery.tables.getData denied, or access denied when querying a dataset in another project
• Check first: BigQuery permissions are granted at the dataset level, not the table level. Cross-project queries require the role in the dataset’s project.
• Likely fix: Grant roles/bigquery.dataViewer on the dataset (not the project) to the querying identity

Terraform and CI/CD service accounts

• Common symptom: Terraform plan or apply fails with 403 on resource creation, modification, or state access
• Check first: The service account running Terraform needs permissions for every resource type it manages, plus storage.objects.* on the state bucket. See Terraform permission errors for a full walkthrough.
• Likely fix: Grant the minimum set of predefined roles that cover the resources in the Terraform configuration. Avoid roles/editor and use Terraform-specific IAM patterns instead.

When to use this page

This guide covers the general GCP 403 PERMISSION_DENIED error. Use it when:

• You get a 403 and are not sure whether the cause is IAM, an API, or an org policy
• You need a systematic way to diagnose any permission denied error
• You want to understand how GCP evaluates permissions

For more specific errors, use these dedicated guides instead:

• IAM AccessDenied errors for service account IAM bindings, conditional policies, or cross-project access
• API not enabled errors when the error includes SERVICE_DISABLED
• Cloud Storage access denied for bucket or object access, ACLs, or uniform bucket-level access
• Terraform permission errors when Terraform plan or apply fails with 403
• Authentication errors when the error is 401 UNAUTHENTICATED rather than 403

Verifying the fix with testIamPermissions

The IAM testIamPermissions API lets you verify whether an identity has specific permissions without making the actual API call. Use it to confirm a fix worked before re-triggering the operation that was failing:

# Test whether the current gcloud identity has the storage permissions
gcloud projects test-iam-permissions PROJECT_ID \
  --permissions="storage.objects.get,storage.objects.list"

The response lists only the permissions the caller actually has from the set you requested. Any permission absent from the response is missing.

Permission Denied vs related errors

GCP returns several error types that are easy to confuse. Here is how to tell them apart.