Identity-aware proxy

On GKE, Identity-Aware Proxy authenticates every request with Google before it reaches the app. There is no in-app login screen: the app trusts the forwarded x-goog-authenticated-user-email header.

The one hard requirement

warning

Header-trust authentication is only safe when the app is reachable only through the proxy.

Any network path that reaches a pod directly is a path that can set x-goog-authenticated-user-email to any value and be believed. A second ingress added for convenience, a port-forward left open to a shared network, a service mesh route that bypasses the load balancer — each of those turns the strongest sign-in option into the weakest.

The proxy must also strip client-supplied identity headers and re-add them from the verified identity. IAP does this. A hand-rolled reverse proxy may not.

Configure

gke:
  iap:
    enabled: true
    oauthClientSecretName: presponsieve-iap-oauth

service:
  annotations:
    cloud.google.com/neg: '{"ingress": true}'

ingress:
  className: "gce"

keycloak:
  enabled: false
oidc:
  issuerUrl: ""

IAP requires the GCE ingress class. The NEG annotation gives container-native load balancing, so the ingress targets the ClusterIP Service directly without a NodePort.

The OAuth client

Create it in the console, then store it as a Kubernetes secret with client_id and client_secret keys. Never commit these to a values file.

kubectl create secret generic presponsieve-iap-oauth -n presponsieve \
  --from-literal=client_id="$IAP_CLIENT_ID" \
  --from-literal=client_secret="$IAP_CLIENT_SECRET"

The backend timeout

Enabling IAP also renders a BackendConfig. That matters beyond IAP itself: the GCLB default backend timeout is 30 seconds, which is shorter than a long analysis. Past it the load balancer returns an HTML 502 that the app never sees and cannot log.

gke:
  backendConfig:
    enabled: true
    timeoutSec: 600
    drainingTimeoutSec: 60

If you see intermittent 502s on long transcripts and nothing in the application logs, this is the cause.

When not to use it

IAP ties sign-in to Google. If your identity provider is Okta or Entra and you want group mapping, MFA policy, and offboarding to flow from there, use OIDC instead.