Authenticate
Four options. Two are for production, two are not.
| Method | Best for | Requires |
|---|---|---|
| OIDC | Any org IdP, MFA, directory sync | oidc.issuerUrl, oidc.clientId |
| Identity-aware proxy | Zero in-app login, on GKE | A proxy in front, and no direct path to pods |
| Google Sign-In | Quick Google-only login | GOOGLE_CLIENT_ID |
| Login tokens | Bootstrap and break-glass | ACCESS_TOKENS |
Choose before you deploy
This decision is harder to change later than it looks, because it determines whether the app may be reachable directly.
With OIDC, the app authenticates requests itself, so a direct path to a pod is merely undesirable.
With an identity-aware proxy, the app trusts a forwarded header and shows no login screen. A direct path to a pod is then a way to impersonate any user. See Identity-aware proxy.
Login tokens are break-glass
ACCESS_TOKENS exists so you can sign in before SSO is configured, and so you can get back in when your identity provider is down.
A login token bypasses your identity provider, your MFA, and your offboarding process. Someone who leaves the company still has it.
Use it to bootstrap, then remove it from the application secret. Do not carry it into production because it was convenient during evaluation, and do not treat it as a peer of the other three options in this table.
Google Sign-In
GOOGLE_CLIENT_ID enables Google-only login without a full OIDC configuration. Reasonable for a small Google Workspace organisation. It gives you no group mapping and no directory sync, so prefer OIDC once you have more than a handful of users.
Keycloak
keycloak.enabled: true does not install Keycloak. It derives the OIDC issuer from an in-cluster service named <release>-keycloak, which you install separately.
If you already run an identity provider, point oidc.issuerUrl at it and leave this off.