In v0.1.0-alpha.5 we dropped the oauth2-proxy sidecar and moved the frontend to pure SPA PKCE via keycloak-js. The chart's NebariApp template still sets auth.enabled: true alongside spaClient.enabled: true:
https://github.com/nebari-dev/nebari-landing/blob/v0.1.0-alpha.5/charts/nebari-landing/templates/nebariapp.yaml
The operator reads auth.enabled: true as a request to provision the primary (confidential) OIDC client, on top of the public SPA client that spaClient.enabled provisions. So we end up with two clients in the realm but only the SPA one is actually used.
I verified this on a live alpha.5 deploy. There's still a nebari-landing-oidc-client Secret sitting in nebari-system holding the confidential client's credentials, and nothing in the chart reads it. The frontend /config.json only references the SPA client (nebari-system-nebari-landing-spa), and the webapi validates tokens against JWKS rather than using a client secret.
Net effect is an unused confidential client with a valid secret hanging around the realm. Not breaking anything, but it's dead state and a mild security smell.
Two paths I can see for the fix, not sure which is right:
- Drop
auth.enabled: true from the NebariApp template and rely on spaClient.enabled alone. Simplest, but depends on what the operator does when auth.enabled is unset/false alongside spaClient.enabled: true.
- Keep
auth.enabled: true but add an operator-side switch (something like auth.provisionPrimaryClient: false) so callers that only need the SPA client can opt out. More flexible but needs an operator change first.
In v0.1.0-alpha.5 we dropped the oauth2-proxy sidecar and moved the frontend to pure SPA PKCE via keycloak-js. The chart's NebariApp template still sets
auth.enabled: truealongsidespaClient.enabled: true:https://github.com/nebari-dev/nebari-landing/blob/v0.1.0-alpha.5/charts/nebari-landing/templates/nebariapp.yaml
The operator reads
auth.enabled: trueas a request to provision the primary (confidential) OIDC client, on top of the public SPA client thatspaClient.enabledprovisions. So we end up with two clients in the realm but only the SPA one is actually used.I verified this on a live alpha.5 deploy. There's still a
nebari-landing-oidc-clientSecret sitting innebari-systemholding the confidential client's credentials, and nothing in the chart reads it. The frontend/config.jsononly references the SPA client (nebari-system-nebari-landing-spa), and the webapi validates tokens against JWKS rather than using a client secret.Net effect is an unused confidential client with a valid secret hanging around the realm. Not breaking anything, but it's dead state and a mild security smell.
Two paths I can see for the fix, not sure which is right:
auth.enabled: truefrom the NebariApp template and rely onspaClient.enabledalone. Simplest, but depends on what the operator does whenauth.enabledis unset/false alongsidespaClient.enabled: true.auth.enabled: truebut add an operator-side switch (something likeauth.provisionPrimaryClient: false) so callers that only need the SPA client can opt out. More flexible but needs an operator change first.