La rotacion de secretos en Kubernetes casi nunca falla de forma elegante. Lo normal es algo mas incomodo: un token vence, un pod sigue vivo con credenciales viejas, o una app reinicia bien en staging pero raro en prod. Cuando eso pasa, muchos equipos saltan directo a reiniciar todo. Ese reflejo aveces resuelve el sintoma, pero tambien borra pistas y mete ruido justo cuando mas necesitas claridad.
En guardias de SRE me ha servido tratar la rotacion como un cambio operacional con evidencia minima, no como un boton magico. Si un secreto cambia, quiero saber que workloads lo consumen, que parte lee el valor solo al arranque, y que alertas apareceran si hago rollout ahora mismo.
Cuando la rotacion de secretos falla no siempre explota al momento
El patron mas enganoso es este: el secreto ya fue actualizado, pero solo una parte del sistema empezo a usarlo. Algunos pods leen desde variable de entorno, otros desde volumen montado, y otro servicio guarda conexiones abiertas durante varios minutos. Desde fuera parece que todo esta "medio bien". Ese estado medio roto es el que mas tiempo roba.
Por eso prefiero una alerta que diga algo util, no solo "secret changed". Necesito al menos:
- nombre del secreto y namespace
- despliegues o CronJobs que dependen de el
- si el consumo ocurre en arranque, refresh interno o ambos
- si hubo errores de autenticacion despues del cambio
Es la misma idea de preparar senales con contexto antes de tocar produccion. Una senal desnuda obliga al on-call a reconstruir la escena entera, y ahi se va un monton de tiempo.
Que revisar antes de reiniciar pods
Antes de tirar un kubectl rollout restart, hago tres preguntas:
- El secreto cambio de verdad o solo cambió metadata que no consume la app.
- La aplicacion relee credenciales en caliente o necesita proceso nuevo.
- El fallo esta en el secreto, o en el sistema que envia la nueva credencial.
Ese tercer punto importa mucho. Varias veces el error no era Kubernetes sino una cola atrasada de notificaciones, un job que escribia tarde, o un proveedor externo que entregaba el valor con demora. Si no ves esa parte, reinicias pods sanos y el incidente se vuelve mas feo.
Un chequeo pequeno que suele bastar:
kubectl get secret api-credentials -n payments -o yaml
kubectl get deploy -n payments -o json | jq '.items[] | {name: .metadata.name, secrets: [.spec.template.spec.containers[].envFrom[]?.secretRef.name]}'
kubectl rollout status deploy/payments-api -n payments
kubectl logs deploy/payments-api -n payments --since=15m | rg "auth|token|secret|credential"
No es un runbook brillante, pero si ordena la primera media hora. Tambien deja visible si el problema es parcial. Y un incidente parcial mal leido, bueno, se convierte facil en incidente total.
Un runbook pequeno para rotar secretos sin panico
Cuando el servicio no soporta recarga dinamica, uso un flujo simple:
- Confirmar version nueva del secreto y timestamp real de actualizacion.
- Identificar workloads impactados y ordenarlos por criticidad.
- Reiniciar primero un replica set pequeno o una canary si existe.
- Medir autenticacion, latencia y errores de negocio durante 5 a 10 minutos.
- Completar rollout solo si la evidencia sigue limpia.
Si un componente manda emails o links de verificacion al cambiar credenciales, me gusta separar esa prueba de la ruta principal. Para entornos de QA, una direccion desechable puede ayudar a validar la notificacion sin mezclar bandejas reales. Lo importante es que ese paso sea evidencia secundaria, no la prueba central de que el secreto quedo bien propagado.
Tambien conviene hacer visible cualquier backlog de entrega. El articulo sobre hacer visible una cola de notificaciones lentas toca esa idea desde backend, pero en operaciones aplica igual: si la senal externa llega tarde, el operador necesita verlo rapido.
En varios equipos aun aparece un tem email en alguna prueba rapida o un reinicio manual "por si acaso". Yo no diria que sea prohibido, pero si deja deuda. Si la guardia siguiente no entiende por que reiniciaste, el aprendizaje se pierde y el mismo bug vuelve.
Donde ayudan las pruebas de notificaciones
No toda rotacion necesita email, Slack o webhook, pero cuando existen, hay que tratarlos como canales de soporte. Sirven para confirmar que el flujo alrededor del secreto esta sano, aunque no reemplazan logs, metricas ni eventos del cluster.
Algo que si he aprendido a la mala: no mezclar el runbook de credenciales con el runbook de mensajeria. Si cambia una password de base de datos y ademas falla el aviso, primero estabiliza la app. Luego revisas la notificacion. Hacer ambas cosas al mismo tiempo suena eficiente, pero normalmente te deja con dos hipotesis malas en vez de una hipotesis buena.
Checklist para la siguiente guardia
Antes de cerrar el incidente, dejo una nota corta con esto:
- que secreto cambio y a que hora
- que workloads consumian el valor
- si hacia falta reinicio o no
- que error exacto desaparecio tras la rotacion
- que prueba secundaria se uso para validar el flujo
- que duda quedo abierta para horario laboral
No tiene que quedar bonito. Tiene que quedar util. Ese tipo de nota pequeña evita decisiones ciegas despues, y eso ya paga bastante.
Q&A
Debo reiniciar todos los pods apenas rote un secreto?
No siempre. Primero confirma como consume el secreto cada app. Reiniciar sin esa comprobacion es rapido, pero no necesariamente correcto.
Que parte suele faltar en las alertas?
La relacion entre el secreto cambiado y los workloads afectados. Muchas alertas detectan el evento, pero no muestran quien sufrira el impacto real.
Conviene automatizar todo el rollout?
Solo cuando ya entiendes el patron de fallo. Automatizar un proceso confuso hace que el error viaje mas rapido, y eso no ayuda mucho la verdad.
Top comments (0)