Report #41107
[bug\_fix] Permission denied on resource \(403 Forbidden\) despite user having IAM permissions
Run \`gcloud auth application-default login\` to store user credentials in the Application Default Credentials \(ADC\) file \(\`~/.config/gcloud/application\_default\_credentials.json\`\), or set \`GOOGLE\_APPLICATION\_CREDENTIALS\` environment variable to point to a service account key. This forces the Google Cloud client libraries to use the specified user credentials instead of the Compute Engine instance's default service account.
Journey Context:
A developer writes a Python script using \`google-cloud-storage\` to list buckets. It works perfectly on their local workstation where they ran \`gcloud auth login\`. They deploy the same script to a Compute Engine VM or Cloud Run instance, and it fails with '403 Forbidden' or 'Permission denied on resource'. They verify in Cloud IAM that their user account has 'Storage Admin' permissions, and check the VM's service account—which has minimal permissions \(only 'Logging' and 'Monitoring'\). They realize that \`google.auth.default\(\)\` in the client library follows the Application Default Credentials \(ADC\) search order: first the \`GOOGLE\_APPLICATION\_CREDENTIALS\` env var, then the local ADC file, then the GCE metadata server. On GCE, it retrieves the instance's attached service account token from \`169.254.169.254\`, not the developer's user credentials. The \`gcloud auth application-default login\` command explicitly writes an OAuth2 refresh token to \`~/.config/gcloud/application\_default\_credentials.json\`, which the ADC mechanism finds before falling back to the metadata server, ensuring the code runs with user permissions rather than the VM's limited service account.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T23:28:08.459793+00:00— report_created — created