Leer un plan antes de aplicarlo

Terraform trabaja en dos tiempos. Con el plan compara el código con el estado que conoce de la infraestructura y calcula la lista de acciones necesarias para igualarlos; con aplicar, ejecuta esa lista contra la cuenta. El plan no cambia nada: es una predicción que se puede guardar en un archivo, mostrar en texto legible o convertir a JSON con la orden de mostrar el plan en formato JSON, que es lo que leen las herramientas de revisión.

Por eso la revisión de seguridad ocurre sobre el plan y no solo sobre el código: el mismo cambio de dos líneas puede crear un recurso nuevo o destruir uno que contenía datos, y eso solo se ve en la lista de acciones.

En el JSON del plan, cada elemento de resource_changes trae la dirección del recurso, su tipo y un objeto change con la lista actions. Los valores posibles son create, update, delete, read y no-op, y un reemplazo se escribe con dos acciones juntas: ["delete", "create"]. El objeto trae también before y after, con el valor de los atributos antes y después. En el texto de la consola los símbolos equivalentes son +, ~, - y -/+.

El reemplazo es el que más sorprende: un atributo que no se puede cambiar en un recurso vivo obliga a destruir el recurso y crear otro. Si el recurso guardaba datos, los datos no pasan solos al nuevo.

Abre plan.txt y plan.json en la carpeta del escenario. El texto de la consola marca con un comentario el atributo que obliga al reemplazo y un encabezado indica qué recurso «must be replaced». Lo que importa al revisar es la dirección completa del recurso: tipo y nombre separados por un punto, tal como la escribe el plan.

No todo lo que se destruye se reemplaza. Un recurso con la acción delete sola desaparece del código y, al aplicar, de la cuenta. En un cambio de seguridad conviene preguntar quién lo usaba: una identidad borrada puede romper un proceso que dependía de ella, y al revés, una identidad heredada que sobra es justo lo que se quiere borrar. El plan no sabe cuál de las dos es; lo sabe quien conoce el sistema.

La última línea del plan en texto resume el cambio con tres números. Pero un revisor no se fía solo del resumen: cuenta en el JSON las entradas cuya lista de acciones incluye delete, porque un reemplazo cuenta como una destrucción aunque también cree algo. El número que sale es el de recursos que podrían perder datos o dejar de existir con este cambio.