Kubernetes: alerta antes de que expire un token

Los tokens que caducan en Kubernetes rara vez avisan de forma comoda. Lo mas normal es ver primero un sintoma lateral: un job deja de hablar con una API, una integracion externa empieza a devolver 401, o un pod sano en metricas queda medio roto en negocio. En ese punto, el impulso natural es reiniciar algo. A veces ayuda, pero muchas veces solo mueve el problema unos minutos y te quita contexto.

En guardias de SRE me ha servido tratar la expiracion como una senal operativa, no como un detalle de implementacion. Si un token va a vencer pronto, quiero saberlo antes de que caiga el primer flujo importante. Y si ya vencio, quiero ver rapido que workloads quedaron tocados, que margen tengo para rotar, y si el fallo esta en Kubernetes o en el sistema que emite la credencial.

El fallo aparece tarde y por eso engancha

El patron mas pesado es el de degradacion lenta. El token sigue valido en algunos procesos por cache, pero otro componente ya empezo a fallar. Desde fuera se ve raro: latencia estable, CPU normal, y errores de autenticacion subiendo solo en un camino concreto. Ese estado intermedio roba muchisimo tiempo.

Por eso la alerta no deberia decir solo "token expires soon". Me sirve mas cuando trae:

• namespace y secreto o service account implicado
• workloads que consumen esa credencial
• fecha real de expiracion y margen restante
• errores recientes de autenticacion asociados
• enlace rapido al runbook de rotacion

Es la misma idea de rotar secretos sin reinicios ciegos: una senal con contexto baja el ruido y evita decisiones torpes. Cuando esa pieza falta, el on-call tiene que reconstruir el mapa a mano, y ahi se va media incidencia facil.

Que senales pongo antes de que el token venza

No hace falta montar una plataforma gigante. Un primer paso bastante util es medir tres cosas:

1. Cuantos dias u horas le quedan a cada token critico.
2. Que despliegues o CronJobs dependen de el.
3. Si ya hay errores de autenticacion en logs o eventos.

Cuando el token vive en un secreto sincronizado desde otro sistema, tambien intento guardar la hora de emision original. Sin eso, el operador ve el secreto "nuevo" en Kubernetes y asume que todo esta bien, aunque la credencial copiada ya venia casi vencida. Me ha pasado mas de una vez, y se pierde rato en la direccion equivocada.

Un chequeo sencillo puede verse asi:

kubectl get secret payments-api-token -n payments -o json | jq -r '.metadata.name'
kubectl get deploy -n payments -o json | jq '.items[] | {name: .metadata.name, sa: .spec.template.spec.serviceAccountName}'
kubectl logs deploy/payments-api -n payments --since=20m | rg "401|403|token|expired|credential"
kubectl get events -n payments --sort-by=.lastTimestamp | tail -n 20

No es perfecto, pero ordena la primera media hora. Tambien ayuda a separar un problema de expiracion real de un problema de permisos, reloj desfasado o rollout a medias. Ese matiz parece pequeno, pero cambia mucho la respuesta.

Un runbook pequeno para no reiniciar a ciegas

Cuando veo que una credencial esta cerca del borde, sigo este orden:

1. Confirmar expiracion real y sistema dueño del token.
2. Identificar workloads impactados y priorizar los que tocan ingreso o pagos.
3. Validar si la app relee el token en caliente o solo al arranque.
4. Rotar en un servicio pequeno o canary antes del resto.
5. Observar errores de autenticacion, latencia y colas durante 5 a 10 minutos.
6. Completar rollout solo si la evidencia aguanta.

La parte importante no es que el runbook sea elegante. Lo importante es que reduzca apuestas. Si saltas directo al restart global, aveces recuperas disponibilidad, si, pero tambien escondes cual workload estaba mal cableado y cual seguia usando un token cacheado.

Otra cosa que procuro dejar escrita: quien es el owner del token. Suena obvio, pero en incidentes reales aparece mucho credencial "de plataforma" que en verdad depende de un equipo externo, o de una integracion vieja que nadie quiere tocar. Esa ambiguedad hace el incidente mas largo de lo que deberia ser.

Donde encajan las pruebas de notificacion

Algunas rotaciones activan emails, webhooks o mensajes a otro sistema. Eso no prueba por si solo que el token quedo bien, pero si da una capa extra de evidencia. Para entornos de QA o pruebas internas, a veces uso tempmailso o un servicio de free disposable email para revisar una notificacion sin mezclar buzones reales. Lo importante es tratarlo como validacion secundaria, no como la prueba principal.

Si esa notificacion depende de un worker o de polling, me sirve muchisimo revisar tambien algo como este enfoque de polling de inbox con limites sanos. La razon es simple: si el canal auxiliar ya venia lento, puedes culpar al token y perder tiempo. Un tempail perdido en una cola atrasada no te dice nada bueno sobre la salud del cluster.

En otras palabras, primero estabiliza autenticacion. Luego confirma mensajeria. Hacer ambas hipotesis al mismo tiempo parece eficiente, pero casi nunca sale bien del todo.

Checklist para la siguiente guardia

Antes de cerrar, dejo una nota corta con esto:

• que token o secreto estaba por vencer
• quien era el owner real de la credencial
• que workloads consumian ese valor
• si hacia falta reinicio o recarga dinamica
• que error desaparecio despues de la rotacion
• que prueba secundaria use para validar el flujo
• que duda quedo abierta para horario laboral

No tiene que quedar bonito. Tiene que quedar util. Una guardia futura agradece muchisimo esa nota medio fea pero concreta.

Q&A

Conviene alertar por todos los tokens?

No. Empieza por los que sostienen rutas criticas o integraciones externas. Si alertas por todo desde el dia uno, el equipo dejara de mirar la senal bastante rapido.

Reiniciar siempre resuelve?

No necesariamente. Si el token nuevo no llego, o si el sistema emisor entrego una credencial mala, el reinicio solo mueve el error. Primero confirma la causa.

Cuanto margen de expiracion deberia vigilar?

Depende del sistema, pero me funciona separar dos umbrales: uno preventivo para horario laboral y otro mas agresivo para guardia. Ese detalle evita correr por nada, pero tambien evita llegar tarde.