Terraform: drift de IAM con contexto util

El drift de IAM rara vez empieza como un gran incidente. Normalmente aparece como una duda pequena: un permiso que ya no coincide, un rol que alguien toco desde consola, o una politica que sigue viva aunque el modulo diga otra cosa. Cuando esa diferencia se descubre tarde, el equipo pierde tiempo discutiendo si el cambio fue legitimo, urgente o simplemente un parche que nadie documento.

En equipos de plataforma esto pasa mas de lo que gusta admitir. Terraform dice una cosa, AWS muestra otra, y la alerta llega sin pista de blast radius, sin actor probable y sin una referencia clara al ultimo plan aprobado. Ahi es donde conviene tratar el drift como una senal operativa, no solo como una diferencia tecnica.

Por que el drift de IAM casi siempre llega sin contexto

La mayoria de alertas de drift fallan por el mismo motivo: detectan diferencia, pero no explican impacto.

He visto mensajes que solo dicen "drift detected in prod" y ya. Eso obliga al on-call a reconstruir todo a mano:

• que recurso cambio
• si el cambio amplio permisos o los recorto
• si fue una edicion manual o una automatizacion rara
• si el siguiente terraform apply corregira el estado o rompera algo

Esa falta de contexto se parece mucho a otros problemas de observabilidad. En contratos minimos para alertas de produccion, la idea clave era la misma: una alerta util no solo avisa, tambien orienta la primera decision.

Las tres preguntas que una alerta debe responder

Cuando preparo revisiones de drift para IAM, intento que la alerta responda estas tres preguntas en el primer minuto:

1. Que permiso o relacion de confianza cambio exactamente.
2. Quien o que sistema hizo el cambio mas probable.
3. Que riesgo trae esperar hasta la siguiente ventana de apply.

Si no puedes responder esas tres, la alerta todavia esta verde. No importa si el detector sea elegante.

Un ejemplo simple de contexto que si ayuda:

• role: payments-api-prod
• drift: politica inline agregada fuera de Terraform
• scope: acceso adicional a s3:GetObject sobre un bucket sensible
• last_apply: hace 2 dias
• owner: modulo iam/payments-service
• recommended_action: revisar CloudTrail y congelar apply automatico

Con eso, la conversacion cambia bastante. Ya no es "hay drift", sino "hay drift en un rol sensible y si aplicamos ahora vamos a borrar o sobreescribir algo que todavia no entendimos". Parece un matiz chico, pero cambia mucho la calidad de la respuesta.

Un flujo pequeno para revisar drift sin frenar al equipo

Este flujo me ha funcionado bien cuando quiero rapidez sin improvisar demasiado:

terraform plan -refresh-only -out=drift.tfplan
terraform show -json drift.tfplan > drift.json
jq '.resource_changes[] | select(.change.actions == ["update"]) | {address, before: .change.before, after: .change.after}' drift.json
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=payments-api-prod

Lo importante no es correr mas comandos. Lo importante es mirar primero el tipo de diferencia. No todo drift en IAM merece el mismo tono:

• cambios en assume_role_policy suelen pedir mas cuidado
• permisos ampliados sobre datos o secretos suben prioridad rapido
• tags o descripciones raramente justifican una escalada urgente

A veces tambien conviene pausar un pipeline si esta por aplicar automaticamente. He visto equipos corregir demasiado pronto y perder evidencia sobre quien hizo el cambio original. Luego toca adivinar, y adivinar en seguridad cloud sale caro.

Donde entran los correos de aprobacion

Muchos flujos de cambio sensible dependen de un correo de aprobacion o de una notificacion paralela. Esa parte no deberia liderar la investigacion, pero si puede sostenerla. Para probar ese paso sin mezclar bandejas reales, un servicio de correo temporal desechable puede servir en entornos de QA o automatizacion. El truco es no confundir esa prueba con la fuente de verdad del drift.

Tambien ayuda separar bien el ruido de entrega. Si una aprobacion no llega, primero reviso el evento del cambio y luego el canal de correo. Esa disciplina se parece a aislar ruido cuando una senal depende del email: cada capa necesita su propia evidencia, o todo termina mezclado.

En varios equipos aun veo parches con un dummy e mail o un tem email para destrabar pruebas rapidas. Sirve cinco minutos, pero despues nadie sabe si fallo la aprobacion, la regla SMTP o el propio pipeline. Es mejor dejar ese atajo para pruebas bien delimitadas, no para cambios sensibles en prod.

Checklist antes de aplicar o revertir

Antes de decidir apply, revertir o congelar, reviso esta lista:

• el recurso afectado esta etiquetado como critico o sensible
• el cambio amplia permisos, relaciones de confianza o acceso transversal
• existe evidencia de CloudTrail para el actor o proceso que lo hizo
• el ultimo plan aprobado sigue siendo valido con el contexto actual
• el equipo sabe si el drift fue intencional, temporal o accidental
• hay una nota corta para el siguiente turno, aunque sea fea pero clara

Ese ultimo punto parece menor, pero evita muchos errores tontos. En guardias largas, una nota medio imperfecta ayuda mas que una memoria heroica. Si el contexto queda escrito, el siguiente ingeniero entra mejor parado y no repite el mismo analisis de cero.

Q&A

Conviene corregir todo drift de IAM de inmediato?

No siempre. Si el drift toca permisos sensibles, la prioridad puede ser congelar cambios y entender el origen antes de aplicar. Corregir rapido pero a ciegas aveces empeora la situacion.

Que dato falta mas seguido?

El impacto esperado del siguiente terraform apply. Saber que hay drift ayuda, pero saber si el apply borrara, ampliara o restaurara permisos ayuda mucho mas.

Esto reemplaza una revision de seguridad?

No. Esto ordena la primera respuesta. La revision de seguridad sigue siendo necesaria cuando el drift afecta acceso real a datos, secretos o identidades compartidas.