Report #13417
[bug\_fix] GCP 403 Permission Denied on resource despite valid OAuth token due to missing resource-level IAM binding
Grant the specific IAM role \(e.g., \`roles/storage.objectViewer\`\) directly on the target resource \(e.g., the specific Cloud Storage bucket or Pub/Sub topic\) for the service account or user, rather than relying solely on project-level permissions. GCP IAM is hierarchical, but resource-level policies can be more restrictive; the principal must have the necessary role binding on the specific resource being accessed.
Journey Context:
A data engineer deploys a Cloud Dataflow job that reads from a specific GCS bucket \`gs://sensitive-data-raw\`. The job runs under the service account \`[email protected]\`. At the project level, this SA has the \`roles/storage.objectViewer\` role. However, the job fails immediately with a \`403 Forbidden: \[SA\] does not have storage.objects.get access to the Google Cloud Storage object\`. The engineer checks the IAM policy for the project; the role is definitely there. They check the bucket \`sensitive-data-raw\` in the Cloud Console under Permissions. They see that the bucket has 'Uniform bucket-level access' enabled. The bucket IAM policy only contains \`legacyBucketReader\` for a different group, and the \`dataflow-sa\` is not listed. The engineer realizes that because the bucket was created with specific restrictive permissions and uniform access enabled, the project-level IAM does not automatically grant access to the bucket contents. They click 'Grant Access' on the specific bucket, add \`dataflow-sa\`, and assign \`roles/storage.objectViewer\`. The Dataflow job restarts and successfully reads the files.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T18:43:39.651468+00:00— report_created — created