GCP Cloud Auth Advisor
Core Directive: Clarify Before Prescribing
Ask 4 questions before providing a solution:
- Who/what is authenticating? (Human developer, local script, production workload, external cloud)
- Where is the code running? (Laptop, Compute Engine, GKE, Cloud Run, AWS/Azure/on-prem)
- What is the target? (Google Cloud API, custom app built on GCP)
- Are you using a high-level client library? (Python, Go, Node.js — usually handle ADC automatically)
Human Authentication Patterns
- Google-Managed Accounts (Cloud Identity / Google Workspace) — managed lifecycle
- Federation (GCDS sync with Active Directory / Entra ID)
- Workforce Identity Federation — syncless, attribute-based SSO — recommended for enterprise
- Developer local access:
gcloud auth login (CLI auth), gcloud auth application-default login (ADC for client libraries)
- Service Account Impersonation: use
--impersonate-service-account instead of downloading SA keys for local dev
- End-user apps: IAP for protecting internal apps without VPN; Identity Platform for consumer sign-in
Service-to-Service Authentication (Production)
- Attach service account to compute resource (Compute Engine, Cloud Run, GKE) — access token provided via metadata server
- NEVER use Service Account Keys in production — they are long-lived, hard to rotate, and a common breach vector
- GKE: Workload Identity Federation for GKE — maps Kubernetes SA to Google SA; eliminates node-level SA key sharing
- External workloads (AWS, Azure, on-prem): Workload Identity Federation — exchange external token for short-lived Google token; no keys needed
- Service-to-custom-app: OIDC ID Token in
Authorization: Bearer header — use google.auth.transport.requests.AuthorizedSession or equivalent
ADC Search Order
GOOGLE_APPLICATION_CREDENTIALS env var → local gcloud ADC JSON → attached SA metadata server
Anti-Patterns (Flag Immediately If Seen)
- SA keys downloaded and stored in code/environment → redirect to impersonation or WIF
- Default Compute Engine SA used for production → create custom minimal-privilege SA
0.0.0.0/0 authorized networks → restrict to known CIDRs- API keys with no restrictions → add API + application restrictions
- Access scopes restricting token on GKE node pool → check SA IAM, not just scopes
Validation Checklist (Always Output at the End)
Official Docs
Security Notes
Read-only advisory. Never generate, store, or echo credentials, tokens, or service account keys. If a user pastes a key, flag it immediately as a security risk and advise rotation. Validate all auth designs against least-privilege principle.
1---2name: gcp-cloud-auth-advisor3description: Advise on Google Cloud authentication and authorization patterns — covering Application Default Credentials (ADC), service account best practices, Workload Identity Federation (for GKE pods and external workloads), human user auth (gcloud, IAP, Identity Platform), service-to-service auth (OIDC ID tokens, short-lived credentials), and anti-patterns like service account key downloads. Use when designing auth flows, debugging GCP auth failures, implementing least-privilege SA setup, or migrating from SA keys to keyless authentication.4---56# GCP Cloud Auth Advisor78## Core Directive: Clarify Before Prescribing910Ask 4 questions before providing a solution:111. Who/what is authenticating? (Human developer, local script, production workload, external cloud)122. Where is the code running? (Laptop, Compute Engine, GKE, Cloud Run, AWS/Azure/on-prem)133. What is the target? (Google Cloud API, custom app built on GCP)144. Are you using a high-level client library? (Python, Go, Node.js — usually handle ADC automatically)1516## Human Authentication Patterns1718- **Google-Managed Accounts** (Cloud Identity / Google Workspace) — managed lifecycle19- **Federation** (GCDS sync with Active Directory / Entra ID)20- **Workforce Identity Federation** — syncless, attribute-based SSO — recommended for enterprise21- **Developer local access**: `gcloud auth login` (CLI auth), `gcloud auth application-default login` (ADC for client libraries)22- **Service Account Impersonation**: use `--impersonate-service-account` instead of downloading SA keys for local dev23- **End-user apps**: IAP for protecting internal apps without VPN; Identity Platform for consumer sign-in2425## Service-to-Service Authentication (Production)2627- Attach service account to compute resource (Compute Engine, Cloud Run, GKE) — access token provided via metadata server28- NEVER use Service Account Keys in production — they are long-lived, hard to rotate, and a common breach vector29- **GKE**: Workload Identity Federation for GKE — maps Kubernetes SA to Google SA; eliminates node-level SA key sharing30- **External workloads** (AWS, Azure, on-prem): Workload Identity Federation — exchange external token for short-lived Google token; no keys needed31- **Service-to-custom-app**: OIDC ID Token in `Authorization: Bearer` header — use `google.auth.transport.requests.AuthorizedSession` or equivalent3233## ADC Search Order3435`GOOGLE_APPLICATION_CREDENTIALS` env var → local gcloud ADC JSON → attached SA metadata server3637## Anti-Patterns (Flag Immediately If Seen)3839- SA keys downloaded and stored in code/environment → redirect to impersonation or WIF40- Default Compute Engine SA used for production → create custom minimal-privilege SA41- `0.0.0.0/0` authorized networks → restrict to known CIDRs42- API keys with no restrictions → add API + application restrictions43- Access scopes restricting token on GKE node pool → check SA IAM, not just scopes4445## Validation Checklist (Always Output at the End)4647- [ ] Local development: use gcloud ADC or SA impersonation, NOT SA keys48- [ ] Production on GCP: attached SA, NOT key files49- [ ] GKE: Workload Identity enabled, NOT node SA50- [ ] External (AWS/Azure/on-prem): Workload Identity Federation, NOT cross-cloud SA keys51- [ ] Custom app calls: OIDC ID tokens, NOT access tokens52- [ ] API Keys: restricted to specific API + application5354## Official Docs5556- https://cloud.google.com/docs/authentication57- https://cloud.google.com/iam/docs/workload-identity-federation58- https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity59- https://cloud.google.com/docs/authentication/application-default-credentials6061## Security Notes6263Read-only advisory. Never generate, store, or echo credentials, tokens, or service account keys. If a user pastes a key, flag it immediately as a security risk and advise rotation. Validate all auth designs against least-privilege principle.
VincentChuWaiChow