DEV pod OIDC: client_id rotado por ASI, falta confirmar el client_secret
El login de permisos-movilba-dev fallaba con 'Cliente no encontrado' (HTTP 400 del realm open-id de identidad-gcaba-hml) porque el Secret movilba-env-secrets del pod tenia el client_id VIEJO 5wzb91di-6qm0-5q3h-937f, que ASI dio de baja el 2026-09-29 al regenerarlo bajo RE-1697143. Medido el 2026-09-30 contra /protocol/openid-connect/auth: el id viejo da 400 'Cliente no encontrado' y el nuevo uha8oc6f-4fur-9abd-0gje-vgry5e0j da 401 'Kerberos Unsupported', o sea que el cliente existe y el realm pide Negotiate, que un navegador con sesion AD resuelve y curl no. APLICADO: patch del Secret con el id nuevo mas oc rollout restart deploy/movilba -n movil-ba-dev; rollout completo y /api/health en 200 serviceId 16118. SIN VERIFICAR el client_secret: sigue cargado el del cliente viejo, 32 chars, y no se puede probar desde aca - el grant client_credentials devuelve unauthorized_client tanto con el secret cargado como con uno deliberadamente incorrecto (control corrido), asi que ese probe no discrimina nada. Si ASI roto tambien el secret, el login va a fallar un paso mas adelante, en el callback, con invalid_client, y ya no con 'Cliente no encontrado'. Los client_secret fueron enviados por mail a Tadeo Bello, no a Elazar (docs/gcaba-gitlab-migracion/README.md). QA tiene el mismo cambio pendiente: id viejo uc7hm8yd-cnox-nf1w-c3j8, nuevo v8pfowz2-57om-bec9-i8qk-Yrey28bd97, RE-1697147. No hay ticket equivalente para PROD.
Activity
-
coder03-mba-l-cc 2026-09-30: root cause CONFIRMED from the DEV pod log, not inferred. The callback token exchange returns unauthorized_client / 'Invalid client or Invalid client credentials' (CallbackRouteError, provider keycloak), so AUTH_KEYCLOAK_SECRET in movilba-env-secrets is still the OLD client's - ASI rotated the secret together with the client_id. NextAuth surfaces it as /auth/error?error=Configuration. The new client_id is correct: the real Keycloak login form is now reached, which the decommissioned id never allowed. Workaround APPLIED so DEV is usable meanwhile: AUTH_MODE patched oidc -> both in the same Secret plus a rollout restart, which is the dev opt-in documented in src/lib/global-settings.ts:31 and leaves the Keycloak button in place. Verified after restart: pod logs 'AUTH_MODE raw=both resolved=both', /api/health 200 serviceId 16118, /user/login 200. Elazar's account epimentel@buenosaires.gob.ar is active with a bcrypt hash, password_expires_at 2026-12-06, locked_until already in the past. Still BLOCKED on the real fix: the client_secret for uha8oc6f-4fur-9abd-0gje-vgry5e0j, which ASI mailed to Tadeo Bello. Not present in the Gmail account connected to this session (elazar.pimentel@pensanta.com), searched by ticket number, client id and OIDC terms. QA leg is unreachable from lezama and measured separately: api.ocp4-qa.gcba.gob.ar:6443 times out while api.ocp4-dev answers 200 in the same minute, and permisos-movilba-qa.gcba.gob.ar returns 503.
-
coder03-mba-l-cc 2026-09-30: DEV OIDC FIXED and verified. Ricci mailed Elazar the regenerated client_secret on 2026-09-29 16:27 (DEV and QA) plus a new DB password; the ticket resolution mails had said the secret went only to Tadeo Bello, so that line was incomplete. Probe that finally discriminates the secret, with both controls, against /protocol/openid-connect/token using grant_type=authorization_code and a junk code - client authentication runs BEFORE the code is evaluated, unlike client_credentials where the grant-enabled check short-circuits it: new client_id uha8oc6f-4fur-9abd-0gje-vgry5e0j + new secret gives 400 invalid_grant 'Code not valid' (client authenticated, only the junk code refused = the GOOD answer); old client_id 5wzb91di-6qm0-5q3h-937f + new secret gives 401 invalid_client; new client_id + a deliberately wrong secret gives 401 unauthorized_client. So Ricci's note 'los CLIENT ID siguen siendo los mismos' is wrong - the old id is decommissioned and the new one is what works. APPLIED: oc patch on Secret movilba-env-secrets setting AUTH_KEYCLOAK_SECRET to the new DEV value and AUTH_MODE back to oidc (it had been moved to 'both' as a temporary password fallback), then oc rollout restart deploy/movilba -n movil-ba-dev. Verified after the rollout: pod logs 'AUTH_MODE raw=oidc resolved=oidc', /api/health 200 serviceId 16118, /user/login 200. NOT applied: the new DB password - the DATABASE_URL currently loaded still works, verified by querying movilba_dev, so it is not swapped for an untested value without Elazar's word. Secrets stored only in the git-ignored ~/.llmmsg-env overlay on lezama, never in a tracked file. QA still pending and unreachable from lezama; asked proxy-mba-w-cc on whey to measure reach to api.ocp4-qa.gcba.gob.ar:6443 and permisos-movilba-qa.gcba.gob.ar before anything is applied there.
-
coder03-mba-l-cc 2026-10-02: cerrado por la nota del 2026-09-30 05:46 - client_secret regenerado aplicado al Secret del pod DEV y login verificado; no queda nada abierto en el titulo.