Proteger terraform state privado sin VPN

Cloudflare documentó cómo proteger terraform state privado sin levantar una VPN: cerró por completo el endpoint público de la storage account donde guarda su estado y resolvió el arranque con un bootstrap en dos fases. El resultado, según el equipo de su área de autenticación en dev.to (22 de junio de 2026): cero superficie pública en su cuenta de estado de producción.

El archivo state de Terraform es el inventario completo de tu infraestructura cloud, y según el proveedor guarda secretos en texto plano: connection strings, contraseñas generadas y claves de API. Por defecto vive en una storage account con un endpoint público protegido solo por una access key. Proteger terraform state privado es eliminar esa superficie pública para que, si la key se filtra, el atacante no se quede con el diagrama entero de tu nube.

¿Qué información sensible contiene tu archivo state de Terraform?

Ponele que corrés terraform apply para levantar una base de datos administrada. Terraform genera la contraseña, la usa y la guarda. ¿Dónde? En el state, en texto plano.

Eso es lo que mucha gente subestima. El state no es un log inocente: es un JSON que describe cada recurso que tenés corriendo y, dependiendo de los providers, arrastra adentro connection strings, claves y secretos generados. Como lo resume el equipo de Cloudflare, “es un mapa completo de cada recurso que ejecutás”. Si alguien lo lee, no tiene que enumerar nada. Le pasaste el plano dibujado.

La diferencia entre estado local y remoto importa acá. El local vive en tu disco (cómodo, pero no sirve para trabajar en equipo). El remoto vive en una storage account compartida, y ahí es donde aparece la pregunta incómoda: ¿quién más puede llegar a ese archivo? Ya lo cubrimos antes en gestor de secretos de Cloudflare.

¿Por qué un endpoint público en cloud storage es un problema de seguridad crítico?

Así funciona en la mayoría de los setups por defecto: el state remoto queda en una storage account con un endpoint público, accesible desde cualquier IP de internet, y la única barrera es una access key. Una sola.

El problema es la “protección” que creés que tenés. Una access key es un secreto largo, sí, pero termina copiada en variables de entorno, en runners de CI, en archivos de config, a veces hasta pegada en un canal de chat para sacar de un apuro a alguien. Se filtra una sola vez y el atacante no tiene que romper nada: se conecta al endpoint público, baja el state y ya tiene credenciales válidas más el mapa de toda tu nube. Cloudflare lo plantea sin vueltas: una empresa que vende autenticación no puede dejar las llaves de su propio reino en internet abierto.

¿La expectativa del usuario promedio? Que “está en la nube, está seguro”. No siempre.

El problema del huevo y la gallina: bootstrap de Terraform state

Acá viene el primero de los tres traps que documenta el artículo, el único que desarrollan en detalle. El remote state necesita un backend que ya exista antes de que Terraform pueda correr. Pero ese backend (la storage account, la red, el camino de acceso) es a su vez infraestructura, y vos querés que Terraform la administre como todo lo demás. Relacionado: almacenar el estado en la nube.

El círculo se cierra solo: no podés usar la storage account para guardar el estado de la storage account que todavía no existe. Mucha gente se queda trabada justo ahí, mirando un error que parece un problema de permisos cuando en realidad es un problema de orden.

Bootstrap en dos fases: cómo resolver el backend circular

La salida que describe Cloudflare es un bootstrap deliberado en dos fases. Nada mágico, pero hay que hacerlo en orden.

• Fase 1, con state local: corrés Terraform contra tu disco y creás solo lo mínimo indispensable: la storage account de estado, la red donde va a vivir y el camino de acceso. Nada más.
• Fase 2, migración a remoto: cambiás el bloque backend de local a remote y migrás el archivo de estado, que ya existe, hacia adentro de la cuenta que acabás de crear.

Desde ese momento, esa capa de bootstrap se administra a sí misma de forma remota, igual que el resto de tu infraestructura. Son, como dicen ellos, “unos minutos de sentir que estás parado en una escalera que todavía estás construyendo” antes de que todo encaje. El truco está en aceptar que el primer apply va a vivir en tu máquina, y que eso está bien porque es transitorio.

Arquitectura de remote state sin VPN: tres traps y cómo evitarlos

El artículo menciona que llegar a “cero superficie pública” tiene tres trampas, y reconoce haber caído en la forma de cada una antes de resolverlas. Eso sí: solo detallan la primera (el huevo y la gallina). Las otras dos quedan nombradas, no desarrolladas, así que sería deshonesto inventarte el paso a paso de algo que la fuente no explica. Para más detalles técnicos, mirá pipelines de CI/CD modernos.

Lo que sí queda claro por el planteo general es hacia dónde apuntan: una vez resuelto el bootstrap, el desafío pasa a ser dar acceso restringido sin sumar overhead de administración, y hacer la transición sin downtime ni perder el estado en el camino. El objetivo declarado es contundente: la cuenta de estado de producción de Cloudflare no tiene ninguna superficie pública.

¿Cómo proteger terraform state privado sin exponer el backend?

La idea de fondo es que no hace falta una VPN cuando tus aplicaciones y tu CI/CD ya viven dentro de la misma red cloud. Si el que necesita leer el state está adentro, no tenés que abrir nada hacia afuera.

• Storage account sin endpoint público: el cambio de raíz. Si no hay puerta a internet, una access key filtrada no alcanza para llegar al archivo.
• Network rules restrictivas: permitís solo el rango o la subred donde corren tus pipelines, y bloqueás el resto por defecto.
• Identidades administradas (managed identities): en vez de access keys que andan dando vueltas, el runner se autentica con una identidad de la propia nube.
• Autenticación y autorización separadas: una cosa es quién sos y otra qué podés tocar. Mantenelas como capas distintas.

Si estás montando este tipo de pipeline en infraestructura propia y necesitás hosting o dominios en Argentina para el resto del stack, donweb.com cubre esa parte mientras vos te concentrás en cerrar la cuenta de estado.

Comparativa: estado local vs remoto vs remoto privado

Modelo	Colaborativo	Seguridad	Complejidad de setup
State local	No (vive en tu disco)	Depende de tu máquina, no se comparte	Mínima
Remoto público	Sí	Baja: endpoint abierto + access key como única barrera	Media
Remoto privado	Sí	Alta: sin endpoint público, acceso por red e identidad	Alta: requiere bootstrap en dos fases

La lectura es directa: el modelo privado te da lo mejor de los dos mundos (colaboración real y superficie cerrada), pero te cobra el peaje del bootstrap inicial. Para un proyecto personal, el remoto público zafa. Para algo en producción con secretos adentro, no.

Errores comunes al asegurar el state de Terraform

• Dejar el state local olvidado tras el bootstrap. Terminás la fase 1 y el archivo queda en tu disco con secretos en plaintext. Corrección: migralo en la fase 2 y borrá la copia local una vez confirmada la migración.
• Confiar en la access key como única defensa. La key se filtra y listo. Corrección: cerrá el endpoint público y sumá network rules e identidades administradas como capas extra.
• Querer crear el backend con el backend que todavía no existe. Es el huevo y la gallina, y trabás todo. Corrección: arrancá con state local solo para crear la fundación, después flipeás a remoto.
• Subir el state a un repo git para “compartirlo”. Cualquiera con acceso al repo lee tus secretos, y el historial queda para siempre. Corrección: usá backend remoto privado, nunca el control de versiones.

Preguntas Frecuentes

¿Cómo hago que mi terraform state no esté en internet público?

Cerrá el endpoint público de la storage account donde guardás el state y restringí el acceso por network rules a la red donde corren tus pipelines. Si tu CI/CD vive en la misma nube, no necesitás VPN: el tráfico nunca sale a internet. Es el enfoque que Cloudflare aplicó en su cuenta de estado de producción. Más contexto en automatización segura con CI/CD.

¿Qué información sensible guarda el terraform state?

El state guarda el inventario completo de tus recursos y, según los providers que uses, secretos en texto plano: connection strings, contraseñas generadas y claves de API. Por eso un state filtrado entrega tanto el mapa de la infraestructura como credenciales válidas para entrar.

¿Necesito una VPN para proteger un remote state de Terraform?

No, si tus aplicaciones y tu CI/CD ya corren dentro de la misma red cloud. Alcanza con eliminar el endpoint público y permitir el acceso solo desde esa red mediante network rules e identidades administradas. La VPN recién entra en juego si necesitás acceder al backend desde fuera de la nube.

¿Cómo creo el backend si Terraform necesita el backend para crearlo?

Con un bootstrap en dos fases. Fase 1: corrés Terraform con state local y creás solo la storage account, la red y el acceso. Fase 2: cambiás el bloque backend de local a remoto y migrás el estado existente hacia adentro de la cuenta recién creada. Desde ahí esa capa se administra sola de forma remota.

¿El state remoto privado sirve para trabajar en equipo?

Sí. El modelo remoto privado mantiene la colaboración (el estado es compartido y consistente para todo el equipo) y le suma seguridad al cerrar la superficie pública. El costo es el bootstrap inicial de dos fases, que se hace una sola vez por entorno.

Conclusión

Lo que cambió acá no es una herramienta nueva, es una postura: tratar el archivo de estado como lo que es, el activo más sensible de tu nube, y no como un detalle de configuración. El caso de Cloudflare (publicado el 22 de junio de 2026) muestra que llegar a cero superficie pública es posible sin VPN, pero que el camino tiene una trampa real al arranque.

¿Qué hacer mañana? Andá a tu storage account de estado y fijate una sola cosa: ¿tiene endpoint público? Si la respuesta es sí, ya sabés por dónde empezar. Cerrá la puerta, migrá con el bootstrap en dos fases y dejá las access keys de single point of failure en el pasado.

Fuentes

• Take your Terraform state off the public internet (without standing up a VPN) – artículo original del equipo de Cloudflare en dev.to (22/06/2026)
• Terraform State – documentación oficial de HashiCorp sobre el archivo de estado
• Backends – documentación oficial de HashiCorp sobre configuración de backend remoto