Terraform 1.17.0 añade variables en proveedores y un refresco más selectivo

HashiCorp publicó Terraform 1.17.0 el 21 de octubre con dos cambios que afectan momentos distintos del ciclo de infraestructura: permite usar variables y locals en los requisitos de proveedor y añade un refresco selectivo con -minimal-refresh, que reduce las lecturas de recursos que aparecen sin cambios en el plan inicial. La release también actualiza la compilación a Go 1.26.10, que deja de confiar en certificados emitidos por ciertas CA intermedias de eMudhra comprometidas.

Requisitos de proveedor menos rígidos, con una frontera

En configuraciones multi-organización, el requisito de proveedor suele variar entre entornos o cuentas, aunque el resto del módulo sea común. Hasta ahora, declarar esa dirección y su versión dentro de required_providers limitaba cuánto podía parametrizarse esa decisión. Terraform 1.17.0 permite referenciar allí variables constantes y valores locales, por ejemplo, para formar el namespace de un registro privado o centralizar la versión del proveedor.

La condición es deliberada: las variables constantes y no pueden depender de resultados dinámicos que solo aparecen al planificar recursos. Terraform necesita resolver la fuente y versión del proveedor antes de inicializarlo; no puede esperar a que un recurso genere un valor durante el plan para decidir qué plugin instalar. En el cambio de código asociado, HashiCorp muestra una variable de organización declarada como constante y un local que fija la versión, un patrón útil para módulos reutilizados sin convertir la instalación en una búsqueda circular.

-InfraCrew dice: El proveedor puede depender del nombre de la organización; todavía no puede depender de un ID que el propio proveedor tendría que crear.-

En la práctica, esto puede reducir copias de módulos que solo existían para distinguir la cuenta o el registro. No convierte cualquier expresión en una fuente válida: los equipos deben revisar qué valores se evalúan antes de init, comprobar la compatibilidad de sus módulos y conservar una referencia de versión reproducible. El beneficio aparece cuando la variación es conocida antes de ejecutar recursos, no cuando depende de datos recién calculados por la infraestructura.

-minimal-refresh cambia el momento de las consultas

El argumento -minimal-refresh introduce una ruta distinta para planificar. Terraform empieza con el estado que ya conserva y calcula el plan; si un recurso queda en no-op, evita refrescarlo contra el proveedor. Si aparece un cambio propuesto, actualiza el estado de ese recurso y vuelve a planificarlo. La nota de versión resume el resultado como refrescar solo recursos con cambios propuestos.

Eso puede reducir lecturas contra APIs cloud o plataformas con muchos objetos sin cambios, pero no es una promesa de que todo plan sea más rápido. El proveedor sigue participando en los recursos que requieren una decisión y puede indicar que una diferencia de configuración no necesita una modificación real. A cambio, la observación de cambios remotos en recursos no-op queda ligada al estado que Terraform ya tenía; el equipo debe entender qué antigüedad puede tener ese estado antes de usar la opción en automatización habitual.

-InfraCrew dice: Ahorrar llamadas al proveedor es útil; enterarse tarde de un drift porque el estado local quedó viejo no lo es tanto.-

El cambio merece una prueba controlada con el backend y proveedores reales del equipo, comparando el plan habitual con el resultado de la opción y verificando cómo se detecta el drift en recursos quietos. No mezcles esa validación con un apply automático: primero comprueba que la propuesta mantiene la semántica esperada para recursos cambiados, dependencias y valores calculados.

Una actualización de Go con efecto en la confianza

La release también incorpora Go 1.26.10. HashiCorp señala que esa versión deja de confiar en certificados emitidos por un conjunto de CA intermedias eMudhra comprometidas e identifica CVE-2026-111943. Si un proveedor interno o un endpoint de infraestructura presenta una cadena emitida por esas CA, su conexión podría dejar de validarse tras actualizar; conviene revisar los certificados y la ruta de confianza en los entornos afectados antes de desplegar Terraform 1.17.0 de forma masiva.

La actualización combina, por tanto, una mejora de parametrización, un cambio en cómo se decide refrescar recursos y un ajuste en la confianza de certificados. La adopción exige validar la flota real: en repositorios pequeños puede ser sencilla, pero en una flota de pipelines conviene probar primero init y los planes representativos, mantener fijadas las versiones de providers y observar la carga que genera el refresco selectivo.

Diccionario de la Crew

Requisito de proveedor — bloque que fija la fuente y la versión del plugin que Terraform necesita instalar.
Variable constante — entrada cuyo valor está disponible antes de planificar recursos y puede usarse al inicializar Terraform.
Local — valor calculado dentro de la configuración para reutilizar una expresión.
Refresco — consulta del estado real de un recurso al proveedor durante la planificación.
No-op — recurso cuyo plan no propone cambios.
Drift — diferencia entre la infraestructura real y el último estado que Terraform conoce.

Fuentes

HashiCorp Terraform, release v1.17.0 | https://github.com/hashicorp/terraform/releases/tag/v1.17.0
HashiCorp Terraform, diseño de -minimal-refresh (#35290) | https://github.com/hashicorp/terraform/issues/35290