Cómo validar correos de Alertmanager tras rotar secretos en Kubernetes

Rotar credenciales SMTP en un clúster parece un cambio pequeño, pero muchas incidencias nacen justo ahi. El Secret se actualiza, el deploy sale verde, los pods vuelven, y todo el mundo asume que Alertmanager seguirá enviando correos como si nada. Luego llega la noche, entra una alerta real, y el equipo descubre que el receptor correcto nunca recibió nada. Ese momento no es dramatico por la rotación en sí; lo es porque casi nadie validó el último tramo del flujo.

En equipos de plataforma esto pasa más de lo que deberia. Cuando alguien busca best throwaway email o free temp email, normalmente no está intentando montar una chapuza. Está buscando una manera limpia de comprobar que la notificación salió desde el sistema correcto, con el contenido correcto, y sin ensuciar la bandeja real del on-call. Si el proceso se siente facil de repetir, el cambio da mucha más confianza.

Donde suele romperse el flujo despues de rotar secretos

El fallo no siempre está en Kubernetes. A veces el Secret nuevo sí se montó, pero el proceso que envía correo no recargó configuración. Otras veces la contraseña cambió bien, pero el relay SMTP rechaza el remitente, el puerto, o el modo TLS esperado. Tambien pasa que Alertmanager sigue funcionando, solo que la ruta que querías validar nunca se disparó con las labels correctas.

Por eso conviene separar tres preguntas:

• ¿El Secret nuevo existe y tiene el valor esperado?
• ¿El componente que envía correo leyó ese valor nuevo?
• ¿La alerta canaria llegó a una bandeja aislada y verificable?

La documentación de Kubernetes Secrets y la de Alertmanager configuration ayudan a revisar el cableado, pero en la practica el error suele aparecer en la unión entre ambos. Un YAML correcto no garantiza un correo correcto.

Un patron practico para validar el cambio sin tocar el on-call real

El patrón más estable que he visto es bastante simple:

1. Crear una alerta canaria que no pagee a nadie.
2. Asociarla a una bandeja temporal exclusiva para esa validación.
3. Etiquetar la ejecución con un release_id o un change_id.
4. Confirmar que el correo llegó con asunto, destinatario y contexto esperados.
5. Cerrar la validación dejando evidencia mínima en el runbook o en el ticket.

La clave es que esa bandeja no se comparta con otras pruebas. Si mezclas validaciones viejas, retries y pruebas de otras personas, pierdes señal. Es el mismo principio que hace útiles los correos de onboarding en SaaS: una intención por bandeja, una lectura clara por escenario.

También aplica a flujos más nuevos donde varias automatizaciones generan mensajes distintos en paralelo. En esos casos, aislar emails de agentes LLM en flujos automatizados enseña la misma lección: no mezcles decisión, ejecución y verificación si luego quieres diagnosticar algo rapdido.

Yo haría la prueba justo después del rollout y antes de cerrar el cambio. No la dejaría como "ya la vemos mañana". Cuando el equipo pospone esa comprobación, el contexto se enfría, los logs ruedan y el incidente se volvio más caro de explicar.

Que revisar antes de culpar a Kubernetes

Si el correo no aparece, revisa primero la ruta corta:

• El Secret referenciado por Alertmanager o por el relay sigue apuntando al nombre correcto.
• El deployment realmente reinició los pods que consumen esa credencial.
• La alerta canaria usa labels que caen en el receiver que esperabas.
• El proveedor SMTP no respondió con un rechazo silencioso o una política nueva.

Después revisa la observabilidad. Necesitas enlazar el evento de prueba con los logs del envío y con la bandeja que recibió el mensaje. Si solo miras el dashboard general de alertas, aveces parece que "todo está bien" porque las reglas disparan, aunque la entrega final esté rota.

Aquí también me fijo mucho en las notas del equipo. Si en tickets internos aparece gente escribiendo tepm mail com o temp mailid para referirse a la prueba, no es un drama, pero sí una señal de que el procedimiento sigue demasiado informal. Conviene dejar un paso corto y repetible: qué bandeja crear, qué alerta lanzar, cuánto esperar y qué evidencia guardar.

Checklist corto para pasar el cambio a produccion

Antes de dar por bueno el cambio, yo validaría esto:

• El Secret nuevo está versionado o asociado al cambio concreto.
• Los pods relevantes reiniciaron o recargaron configuración de forma explícita.
• La alerta canaria usa un receiver que nunca notifica al on-call real.
• La bandeja temporal quedó reservada para una sola ejecución.
• El correo llegó dentro de un tiempo esperado, no "cuando pinte".
• Hay algun rastro claro en logs o en el ticket para repetir la validación luego.

No hace falta convertir esta prueba en una ceremonia gigante. Hace falta que un compañero de guardia pueda repetirla en diez minutos, sin abrir cinco dashboards distintos ni adivinar qué cambió. Cuando esa parte está resuelta, el cambio deja de sentirse frágil y pasa a ser operable de verdad.

Preguntas frecuentes

¿Debo probar esto en cada rotación de credenciales?

Sí, al menos cuando el cambio afecta el envío real de correo o el relay asociado. Si rotas secretos sin validar una alerta canaria, estás aceptando un riesgo bastante evitable.

¿Una bandeja temporal no es demasiada sobrecarga para algo tan pequeño?

Normalmente no. Es un coste pequeño comparado con despertar a alguien por una alerta mal encaminada o confiar en una validación que nunca tocó el flujo final.

¿Qué hago si el correo llega, pero tarda mucho más que antes?

Trátalo como una señal amarilla, no como un pass automático. Revisa colas, límites del proveedor y cambios de red. En SRE, "llegó tarde pero llegó" puede ser suficiente para una demo, pero no para una ruta de alerta seria.