Cloud Storage Bucket Access Policy Denied – Real Fix

You're logged into your cloud console, you try to list objects in a bucket, and boom – Access Denied. Or maybe you set up a service account, gave it what you thought was full access, but your script throws a 403 Forbidden. I've seen this with clients using AWS S3, Google Cloud Storage, and Azure Blob Storage. Last month, a small e-commerce client had their entire backup pipeline break because a junior admin accidentally deleted a bucket policy.

Why This Happens

The root cause is almost always one of these:
- The bucket policy explicitly denies access.
- The role or IAM policy attached to your user doesn't include the right action.
- The bucket is in a different account/project and cross-account access isn't set up properly.
- You used the wrong bucket name or path in your request.

Don't waste time checking network or DNS – 9 times out of 10, it's a permission issue.

How to Fix It

Step 1: Check the Bucket Policy

The bucket policy is a JSON document that controls who can do what. If it says Deny, nothing else matters.

For AWS S3:

aws s3api get-bucket-policy --bucket your-bucket-name

If you get an error saying no policy exists, that's fine – it means there's no explicit deny. But if there is a policy, look for Effect: Deny. I've seen policies where someone added a condition like StringNotEquals aws:SourceIp that blocks your IP.

For Google Cloud Storage:

gsutil iam get gs://your-bucket-name

Same idea – look for role: roles/storage.objectViewer or similar. If you see allUsers with a deny, that's your problem.

For Azure Blob:

az storage container policy list --account-name your-account --container-name your-container

Step 2: Check the IAM Role or User Permissions

Even if the bucket policy allows, your user or service account needs the right IAM role.

AWS:

aws iam list-attached-user-policies --user-name your-user

Make sure your user has a policy like AmazonS3ReadOnlyAccess or at least s3:GetObject and s3:ListBucket. I had a client last week who gave their Lambda function the role AWSLambdaBasicExecutionRole – which has zero S3 permissions. Easy mistake.

Google Cloud:

gcloud projects get-iam-policy your-project --format=json

Look for the service account email and see if it has roles/storage.objectViewer or roles/storage.admin. If it only has roles/storage.legacyBucketReader, that might not be enough for listing objects.

Azure:

az role assignment list --assignee your-user --scope /subscriptions/your-sub

Step 3: Fix the Bucket Policy

If you see a deny statement, remove it or change it to Allow. Here's a typical fix for AWS S3 when you want to allow a specific IAM user from another account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/your-user"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

Google Cloud:

gsutil iam ch user:your-email@domain.com:objectViewer gs://your-bucket-name

Azure:

az role assignment create --role "Storage Blob Data Reader" --assignee your-user --scope "/subscriptions/your-sub/resourceGroups/your-rg/providers/Microsoft.Storage/storageAccounts/your-account"

Step 4: Verify with a Test Request

Don't just assume it's fixed – test it.

AWS:

aws s3 ls s3://your-bucket-name

Google Cloud:

gsutil ls gs://your-bucket-name

Azure:

az storage blob list --account-name your-account --container-name your-container

What to Check If It Still Fails

If you still get Access Denied after fixing the policy and role, check these three things:

1. Cross-account bucket settings – For AWS, make sure the bucket's ACLs (if enabled) don't block access. Also check that the bucket isn't using BlockPublicAccess settings that override your policy.
2. Service account key – If you're using a service account JSON key for Google Cloud, make sure you downloaded the correct one. I've seen people copy the wrong key file from a different project.
3. Bucket name typo – Double-check the bucket name. Sounds stupid, but I've spent 30 minutes debugging a script only to find a missing hyphen.

If none of that works, check the cloud provider's status page – sometimes it's their issue, not yours. But 99% of the time, it's a policy or role problem. Fix that and you're back in business.