Summary of the issue
Description
In some environments, the metadata server returns the logged-in user's email (e.g., user@google.com or a workforce identity) rather than a standard service account email.
Because this user email matches the standard email regex check in google-auth, the library incorrectly assumes the environment is running with a standard service account.
As a result:
- The SDK attempts to query the Regional Access Boundary (RAB)
allowedLocations endpoint using this user email.
- The endpoint rejects the request because it only supports service accounts, resulting in an API error.
- This triggers a logged failure (downgraded to debug in
2.55.1, but still executing the unnecessary HTTP request) on common commands like gcloud config set project.
Historically, auth libraries assumed all compute workloads had an attached Google Service Account (GSA). However, the metadata server responses can vary based on identity configurations:
- Standard SA-backed instances return a normal email address.
- GKE Workload Identity Federation instances return the pool id or a principal string.
To prevent SDKs from making malformed allowedLocations API calls using non-email strings, a guardrail was recently implemented. SDKs validate that the metadata server response conforms to a standard email pattern (e.g., ^[^@]+@[^@]+\.[^@]+$) before initiating a RAB lookup. If it fails this validation, the RAB lookup is skipped.
When the metadata server returns an actual user email, it bypasses this regex guardrail. The SDK treats the user email as a service account and proceeds with the failing lookup.
For additional details, see : b/534822972
Summary of the issue
Description
In some environments, the metadata server returns the logged-in user's email (e.g.,
user@google.comor a workforce identity) rather than a standard service account email.Because this user email matches the standard email regex check in
google-auth, the library incorrectly assumes the environment is running with a standard service account.As a result:
allowedLocationsendpoint using this user email.2.55.1, but still executing the unnecessary HTTP request) on common commands likegcloud config set project.Historically, auth libraries assumed all compute workloads had an attached Google Service Account (GSA). However, the metadata server responses can vary based on identity configurations:
To prevent SDKs from making malformed
allowedLocationsAPI calls using non-email strings, a guardrail was recently implemented. SDKs validate that the metadata server response conforms to a standard email pattern (e.g.,^[^@]+@[^@]+\.[^@]+$) before initiating a RAB lookup. If it fails this validation, the RAB lookup is skipped.When the metadata server returns an actual user email, it bypasses this regex guardrail. The SDK treats the user email as a service account and proceeds with the failing lookup.
For additional details, see : b/534822972