Authentication Flow
The gateway uses two independent auth mechanisms in sequence:
- Worker → cf-proxy:
X-Internal-Auth-Token(shared secret) - cf-proxy → Cloud Run: GCP identity token (OIDC, from instance metadata)
Why two auth layers?
X-Internal-Auth-Tokenguards the tunnel ingress from traffic that bypasses the Worker (e.g. direct requests to the internal hostname). CF Access apps were removed from internal hostnames because Cloudflare stripsCF-Access-*headers from same-zone Worker subrequests, making service token auth unworkable there.- The GCP identity token lets Cloud Run enforce that only the gateway VM SA can invoke the service — no other caller can forge this token.
Token material
| Secret | Source (at deploy time) | Consumer |
|---|---|---|
INTERNAL_AUTH_TOKEN | random_password in iac-api-gateway/gateway/secrets.tf | Worker (via CF Secrets Store) + cf-proxy (via GCP SM) |
| GCP identity token | Instance metadata server (runtime) | cf-proxy → Cloud Run |
| CF tunnel token | cloudflare_zero_trust_tunnel_cloudflared_token in secrets.tf | cloudflared on the VM |
Related pages
- Secret distribution — how
INTERNAL_AUTH_TOKENis provisioned to both stores - Cloudflare Workers — Worker-side token resolution
- Gateway VM — cf-proxy token validation logic