Cloud Storage Access Denied (403): Fix IAM, ACL and Signed URL Errors

Why Cloud Storage returns access denied

Think of Cloud Storage like a building with a security desk. Every request has to pass four checks before it gets through:

1. Caller: who is making the request (user account, service account, workload identity, or anonymous)
2. Permission: the specific action being attempted (storage.objects.get, storage.objects.list, etc.)
3. Resource: the bucket or object the action targets
4. Policy layer: the IAM policy on the resource, plus any higher-level restrictions like organisation policy constraints or VPC Service Controls

If the caller’s badge (identity) does not match the access list (IAM policy) for the floor (resource) and the action (permission) they are requesting, the security desk turns them away with a 403.

Use this page when…

• Reading or downloading a Cloud Storage object fails with 403
• Listing objects in a bucket returns access denied
• A signed URL that worked before now returns 403
• You granted allUsers access but public requests still fail
• Terraform, your application, or gcloud cannot read from or write to a bucket
• You see Anonymous caller in the error and do not know why
• You are unsure whether to fix this with IAM, ACLs, or signed URLs

For broader GCP 403 errors beyond Cloud Storage, see GCP Permission Denied Errors. For authentication problems where credentials are not found at all, see Troubleshooting Authentication Errors.

Fast triage checklist

Run through these checks before changing any IAM policy. Most Cloud Storage 403 errors are solved by one of these:

1. Who is actually calling? Read the identity in the error message. It may not be who you expect. A Compute Engine VM uses its attached service account, not your user account.
2. What exact permission is missing? The error message names it. Match the permission (storage.objects.get, storage.objects.list, storage.buckets.get, etc.) to the right IAM role.
3. Is the role granted at the right scope? A role on the project applies to all buckets. A role on a specific bucket applies only to that bucket. Make sure the grant covers the resource in the error.
4. Does the tool need extra permissions? Some tools call storage.buckets.get or storage.buckets.list as part of their workflow. objectViewer does not include these.
5. Is public access prevention enforced? If you are trying to make an object public and it still fails, check whether the bucket or org policy blocks allUsers bindings.
6. Did a signed URL expire? Signed URLs have a fixed expiry. Once past, they always return 403. Generate a new one.

How Cloud Storage access is evaluated

Cloud Storage access control has several layers. Understanding which layers apply to your bucket is the key to fast diagnosis. For a deep comparison, see Cloud Storage IAM vs ACLs.

IAM (the primary layer)

IAM is the recommended way to control Cloud Storage access. You bind a role (containing one or more permissions) to an identity on either the project or the bucket. Permissions inherit down the resource hierarchy: a project-level grant applies to every bucket and object in that project.

Bucket-level vs project-level scope

Granting a role at the project level gives access to all buckets. Granting at the bucket level scopes access to one bucket. Follow the principle of least privilege and prefer bucket-level grants unless the identity genuinely needs access to every bucket in the project.

Legacy ACLs (fine-grained mode)

If a bucket uses fine-grained access control, both IAM policies and per-object ACLs are evaluated. Access is granted if either IAM or an ACL allows the request. ACLs are allow-only. They cannot deny access that IAM grants. The real problem with fine-grained mode is the complexity: you end up managing two permission systems side by side, which is why Google recommends uniform bucket-level access instead.

Uniform bucket-level access (recommended)

With uniform bucket-level access enabled, per-object ACLs are disabled. Only IAM controls access. This makes permission evaluation predictable and eliminates the legacy ACL layer entirely. Once enabled for 90 days, it cannot be reversed.

Public access prevention

Public access prevention is a bucket-level setting (also enforceable via organisation policy) that blocks allUsers and allAuthenticatedUsers bindings. When enforced, IAM commands to grant public access succeed silently but the access is blocked.

Higher-level policy restrictions

VPC Service Controls perimeters, IAM deny policies, and organisation policy constraints can all block access that IAM would otherwise allow. If your IAM policy looks correct, check for restrictions at the org or folder level.

Error message and likely cause

Step 1: Identify the real caller

The identity in the error message is the one that matters, not the identity you think should be calling. The most common mistake is assuming your user account is making the call when a service account is actually being used.

# Check which identity gcloud is using
gcloud auth list

# Check which service account a Compute Engine VM uses
gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE \
  --format="value(serviceAccounts.email)"

# Check Application Default Credentials
gcloud auth application-default print-access-token 2>&1 | head -1

Common caller mismatches:

• Compute Engine / GKE: uses the VM’s attached service account, not your user account
• Cloud Functions / Cloud Run: uses the service’s runtime service account
• Terraform: uses whatever credentials are configured in the provider block or environment
• Anonymous: no credentials were sent. Check your authentication setup or see Troubleshooting Authentication Errors

Step 2: Read the exact missing permission

The error message names the specific permission that was checked and denied. Map it to the role that contains it:

• storage.objects.get (read object data). Included in objectViewer, objectAdmin, admin
• storage.objects.list (list objects in a bucket). Included in objectViewer, objectAdmin, admin
• storage.objects.create (upload objects). Included in objectCreator, objectAdmin, admin
• storage.objects.delete (delete objects). Included in objectAdmin, admin
• storage.buckets.get (read bucket metadata). Included in legacyBucketReader, admin
• storage.buckets.list (list buckets in a project). Included in project-level viewer roles

Be aware that some tools need extra permissions beyond the obvious one. For example, gcloud storage ls (without a bucket path) calls storage.buckets.list, not storage.objects.list. The objectViewer role does not include bucket-level metadata permissions.

Step 3: Check scope (project vs bucket vs object)

A role granted at the wrong scope is the second most common cause after wrong identity. In GCP’s resource hierarchy, permissions inherit downward: project, then bucket, then object.

# Check IAM policy on a specific bucket
gcloud storage buckets get-iam-policy gs://my-bucket

# Check IAM bindings at project level
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:my-sa@my-project.iam.gserviceaccount.com" \
  --format="table(bindings.role)"

# Grant objectViewer at bucket level (preferred for least privilege)
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
  --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# Grant objectViewer at project level (all buckets)
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Step 4: Check uniform bucket-level access and legacy ACL behaviour

The access control model on the bucket determines whether ACLs are in play. For a detailed comparison of both models, see Cloud Storage IAM vs ACLs.

# Check whether uniform access is enabled
gcloud storage buckets describe gs://my-bucket \
  --format="value(iamConfiguration.uniformBucketLevelAccess.enabled)"

# Enable uniform bucket-level access (recommended)
# Warning: cannot be reversed after 90 days
gcloud storage buckets update gs://my-bucket \
  --uniform-bucket-level-access

If uniform access is enabled (returns True): only IAM matters. Object-level ACLs are disabled. If the IAM policy grants the permission, access is allowed.

If uniform access is not enabled (fine-grained mode): both IAM and per-object ACLs are evaluated. Access is granted if either IAM or an ACL allows the request. The complexity comes from having two systems to check. If you cannot find the issue in IAM, check the object’s ACL.

# View ACLs on a specific object (only relevant in fine-grained mode)
gcloud storage objects describe gs://my-bucket/my-object.txt \
  --format="yaml(acl)"

Step 5: Check public access prevention and organisation-level restrictions

If you are trying to make a bucket or object publicly accessible and it still returns 403, the most likely cause is public access prevention. This setting blocks allUsers and allAuthenticatedUsers bindings, even when the IAM command to add them succeeds without error.

# Check whether public access prevention is enforced on the bucket
gcloud storage buckets describe gs://my-bucket \
  --format="value(iamConfiguration.publicAccessPrevention)"
# Returns "enforced" or "inherited"

# Check org policy constraints on the project
gcloud org-policies describe storage.publicAccessPrevention \
  --project=PROJECT_ID

Other restrictions that can block access even when IAM allows it:

• Organisation policy constraints: can enforce public access prevention, restrict allowed domains, or limit which locations buckets can use
• VPC Service Controls: perimeters block API access from outside the perimeter, even for identities with correct IAM permissions
• IAM deny policies: explicitly deny specific permissions regardless of allow policies

Step 6: Check signed URL problems

Signed URLs grant temporary access without requiring Google credentials. Think of them as pre-approved visitor passes with an expiry date stamped on them. When they return 403, check these in order:

1. Expiry. Signed URLs have a fixed expiry time set at creation. Once expired, all requests return 403. The fix is to generate a new URL.

2. Signing service account permissions. The service account that signed the URL must have the required permission (e.g., storage.objects.get) on the object at the time the URL is used, not just when it was generated. If the IAM binding was removed after signing, the URL stops working.

3. Wrong HTTP method. A signed URL is scoped to a specific HTTP method (GET, PUT, etc.). Using a different method returns 403. Make sure the method in the URL matches the request.

4. Clock skew. Significant time difference between the signing system and Google servers causes signature validation to fail.

# Generate a signed URL valid for 1 hour
gcloud storage sign-url gs://my-bucket/my-object.txt \
  --duration=1h \
  --service-account=my-sa@my-project.iam.gserviceaccount.com

# Verify the signing service account still has the required permission
gcloud storage buckets get-iam-policy gs://my-bucket \
  --flatten="bindings[].members" \
  --filter="bindings.members:my-sa@my-project.iam.gserviceaccount.com"

Step 7: Confirm the fix safely

After making an IAM change, verify it works without over-granting:

# Test whether a specific identity has a permission on a bucket
# (requires iam.serviceAccounts.getAccessToken on the SA)
gcloud storage ls gs://my-bucket \
  --impersonate-service-account=my-sa@my-project.iam.gserviceaccount.com

# View the effective IAM policy on the bucket to confirm the binding
gcloud storage buckets get-iam-policy gs://my-bucket

IAM changes can take up to 60 seconds to propagate. If the change looks correct but access still fails, wait a minute and retry.

When to use which fix

Choosing the wrong access model is a common reason for follow-up 403 errors. Use this to pick the right approach:

IAM vs ACLs vs Signed URLs vs Public Access

For a detailed comparison of IAM and ACL evaluation, when each applies, and which to use on new buckets, see Cloud Storage IAM vs ACLs.