Google Cloud ADC: fix a stale credential path

Read the credential error before changing permissions

A DefaultCredentialsError raised while opening a local file occurs before a successful authenticated service request. Preserve the exception class and the non-sensitive configuration context. An absent file is a different investigation from a service returning PermissionDenied for an established identity.

Our reproduction had a usable fixture in the well-known local ADC location and a GOOGLE_APPLICATION_CREDENTIALS override pointing to a missing file. The library raised a file-not-found credential error. It did not silently ignore that explicitly configured path and select the fixture instead.

Inspect the environment of the application process

Check the terminal, container, IDE launcher, or service configuration that starts the app. Looking at a different terminal can miss an inherited override. The following diagnostic reports only whether a path is configured and whether that file exists; it never prints credential contents.

A path that exists on the host might still be absent inside a container. Check its existence in the environment where the client library actually runs. Do not solve a mount mismatch by copying private keys into the repository.

python · EXAMPLE

import os
from pathlib import Path

configured = os.environ.get("GOOGLE_APPLICATION_CREDENTIALS")
print({
    "explicit_path_configured": bool(configured),
    "explicit_file_exists": bool(configured and Path(configured).is_file()),
})

Restore the credential mechanism you intended

If the override is stale and local ADC is the intended mechanism, remove it from the relevant launcher or environment configuration. If an explicitly configured federation or credential file is intended, repair that path and its delivery instead. Choose the mechanism before changing anything.

For an authorized local developer setup, gcloud auth application-default login establishes local ADC. It is separate from the credentials used by ordinary gcloud commands. The command below is an interactive setup action, not a diagnostic that should run inside a deployed application.

sh · EXAMPLE

# Run only when local developer ADC is the intended setup.
gcloud auth application-default login

Verify selection without treating it as authorization

After removing the lab override, google.auth.default selected the synthetic authorized-user fixture. That demonstrated credential discovery only: the fixture contained invented values and was never refreshed or used against Google Cloud.

In your real environment, first confirm that ADC resolves through the intended mechanism. Then perform the specific authorized read or other low-impact operation the application needs. Successful credential discovery alone does not establish resource access, quota-project correctness, or token validity.

python · EXAMPLE

import google.auth

credentials, project = google.auth.default()
print({"credential_type": type(credentials).__name__, "project": project})
# Never print credentials, refresh tokens, or access tokens.

Prevent the override from returning

Check whether a shell startup file, IDE run profile, Compose environment, or deployment setting will reintroduce the bad value on restart. Repair that source rather than relying on a one-off change in a terminal.

Keep the exception and the verified configuration change with the investigation. If a later request reaches the service and fails for a different reason, investigate that new evidence separately. There is no reason to grant broader IAM permissions merely to resolve a nonexistent local file.

Know the limits

Reproduced with google-auth 2.62.0 inside a container with no external network. A nonexistent configured path failed; removing that override selected a synthetic local ADC file. No real account, token refresh, metadata identity, or IAM permission was tested.

Sources & further reading

A technical publication by CoreTrailKit.

Browse all articles