Google Cloud client libraries: local user ADC versus Cloud Run service account interoperability

Answer the exact question first

1. Does the client library transparently switch from local user credentials to the production service account when running on Cloud Run?

Yes. The Application Default Credentials (ADC) resolver follows a fixed order:

1. Environment variable GOOGLE_APPLICATION_CREDENTIALS
2. Local gcloud user credentials (the token you get after gcloud auth application‑default login)
3. Metadata server token (only available on Google‑managed VMs, Cloud Run, App Engine, etc.)

When the same code runs on Cloud Run, the third step becomes active. The library automatically requests an access token from the metadata server for the default service account attached to the Cloud Run instance. No code changes are required.

2. Must the production service account receive the same IAM roles granted to the local developer account for identical API access?

Yes. IAM is identity‑specific. The permissions that your local developer user has do not carry over to the Cloud Run service account. For every API you call, the service account must be granted at least the same roles (or a custom role that contains the same permissions). Otherwise the calls will fail with PERMISSION_DENIED, even though the library has switched credentials.

3. Do differing OAuth audiences or scopes between user credentials and service account tokens require separate client configuration?

Generally no. Both token types are issued with the same audience (the service’s API endpoint) and the library automatically requests the minimal set of scopes needed for the API you’re using. The only time you need to adjust configuration is if you explicitly set a custom scopes or audience in code or via environment variables. In that case you must keep those values identical in both environments.

Likely explanation vs confirmed facts

• Likely explanation: The ADC resolver behaves the same across environments, so the library should pick the metadata server token automatically.
• Confirmed fact: The ADC lookup order is documented by Google and is consistent across all official client libraries (Python, Node, Java, Go, etc.).
• Uncertainty: Some libraries expose a scopes parameter that defaults to a minimal set; if your code overrides it, you must ensure the same value locally and on Cloud Run.

Steps to verify in your case

1. Print the credential type locally and on Cloud Run.

   # Python example
   from google.auth import default
   creds, _ = default()
   print('is_user:', creds._is_user())
   print('is_service_account:', creds._is_service_account())
   

   • Locally you should see is_user: True.
   • On Cloud Run you should see is_service_account: True.
2. Check IAM roles for the Cloud Run service account.

   gcloud iam service-accounts get-iam-policy SERVICE_ACCOUNT_EMAIL
   

   Compare the roles granted to the service account with those granted to your local user (via gcloud projects get-iam-policy or the Cloud Console). Add any missing roles with gcloud projects add-iam-policy-binding.
3. Verify token scopes.

   # Use the token printed by the library
   export ACCESS_TOKEN=$(gcloud auth print-access-token)
   curl -H "Authorization: Bearer $ACCESS_TOKEN" https://www.googleapis.com/oauth2/v3/tokeninfo
   echo $ACCESS_TOKEN | base64 -d | jq .scope
   

   Ensure the scopes match the requirements of the APIs you call.

One missing diagnostic detail that could change the recommendation

Does your Cloud Run service use the default App Engine service account or a custom one? If you’re using a custom service account, confirm that it has the necessary IAM roles; otherwise the library will switch credentials correctly but API calls will fail.