Report #17966
[bug\_fix] Error 403: Request had insufficient authentication scopes \(GCE OAuth Scope\)
Stop the GCE VM, edit the instance to change 'Cloud API access scopes' to 'Allow full access to all Cloud APIs' \(or add the specific required scope such as \`https://www.googleapis.com/auth/devstorage.read\_write\`\), and restart the VM. Alternatively, if using the Default Service Account is not required, attach a user-managed service account with proper IAM roles and ensure the \`cloud-platform\` OAuth scope is granted. The root cause is that Google Compute Engine VMs use OAuth 2.0 access scopes as a coarse-grained permission boundary that acts independently of IAM roles; even if the service account has the IAM permission 'storage.objects.create', the VM instance metadata server will not return an access token with the \`devstorage.read\_write\` scope unless that scope was explicitly granted at VM creation time, resulting in a 403 'insufficient authentication scopes' from the GCP API.
Journey Context:
A DevOps engineer creates a GCE VM using the default settings in the Cloud Console, leaving 'Allow default access' selected for API scopes. They SSH into the VM and install the \`gcloud\` CLI. They authenticate using the VM's default service account by running \`gcloud auth activate-service-account --key-file /dev/null\` \(effectively using the metadata server\). They attempt to upload a file to a Cloud Storage bucket using \`gsutil cp localfile gs://bucket/\`. They receive a 403 error: 'Request had insufficient authentication scopes'. They check the IAM permissions for the VM's service account in the Cloud Console and see it has 'Storage Object Admin' assigned at the project level. They are baffled because the IAM permission is clearly present. They try \`gcloud auth list\` and see the service account is active. They check the bucket permissions and see no denials. They then examine the VM instance details and notice 'Cloud API access scopes' is set to 'Allow default access', which only includes scopes for Cloud Logging and Monitoring, but NOT 'devstorage.read\_write'. They realize that GCP OAuth scopes act as a secondary gate: the metadata server will only vend an access token with specific scopes if the VM was granted those scopes at boot time. Without the scope in the token, the Storage API rejects the request despite the IAM binding. The engineer stops the VM, edits it to grant the 'Storage' scope \(or 'Allow full access'\), starts it, and the upload succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T06:51:48.185369+00:00— report_created — created