Terraform lanza tfpolicy: un framework de Policy-as-Code nativo en HCL

Introducción

Los equipos de DevOps y SRE enfrentan un desafío creciente: aplicar políticas de seguridad y cumplimiento a infraestructura cada vez más compleja, distribuida across múltiples clouds y servicios. Las soluciones actuales como Sentinel o OPA requieren languages y herramientas separadas, lo que genera fricción en los workflows y dificulta incorporar contexto dinámico, como las relaciones entre recursos. Esto deja brechas de gobernanza, especialmente cuando las violaciones solo se hacen visibles post-despliegue.

Qué ocurrió

HashiCorp anunció el 31 de julio de 2026 el lanzamiento de tfpolicy, un framework de Policy-as-Code nativo para Terraform, disponible en beta pública dentro de HCP Terraform. A diferencia de herramientas externas, tfpolicy está profundamente integrado al workflow de Terraform y usa HCL (HashiCorp Configuration Language), el mismo lenguaje con el que se define la infraestructura. Esto elimina la necesidad de cambiar de herramientas o aprender un DSL adicional.

El framework permite definir y aplicar políticas en dos puntos clave del ciclo de vida: durante el plan (antes del despliegue) y post-deploy (una vez provisionados los recursos). Además, introduce capacidades antes no disponibles en Terraform, como evaluar políticas basadas en relaciones entre recursos (ej.: «la subred debe belong a un VPC con logging habilitado») y consultar data sources para incorporar contexto externo (ej.: «este bucket debe estar en una región permitida por la política de la organización»).

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para los equipos de DevOps, tfpolicy simplifica la implementación de guardrails en los pipelines de Terraform. Al usar HCL, las políticas pueden ser writing y mantenidas por los mismos engineers que definen la infraestructura, reduciendo la dependencia de equipos de seguridad especializados. Esto acelera el feedback loop: los errores de política se detectan durante el terraform plan, antes de que el cambio llegue a producción.

En seguridad, el framework aborda dos problemas críticos:

1. Supply chain risks: permite controlar qué proveedores y módulos pueden descargarse, evitando el uso accidental de dependencias no aprobadas. Esto mitiga ataques como el typosquatting en el Terraform Registry (ej.: hashicorp/aws vs. hasicoorp/aws).
2. Drift detection: al evaluar políticas post-despliegue, detecta violaciones causadas por cambios manuales o derivas de configuración (ej.: alguien modifica el IAM policy de un role directamente en AWS).

Para las plataformas de cloud, tfpolicy facilita implementar guardrails multi-tenant. Los equipos centralizados pueden definir políticas globales (ej.: «todos los clusters EKS deben tener podSecurityPolicy enabled»), mientras permiten a los equipos de desarrollo override políticas específicas cuando justifican una excepción.

Detalles técnicos

Arquitectura e integración

tfpolicy es un subsistema nativo de Terraform, implementado en Rust (como el core de Terraform desde la versión 1.0). Se integra directamente con el graph de Terraform, que representá las relaciones entre recursos, permitiendo políticas que referencian atributos de otros recursos. Por ejemplo:

variable allowed_locations = ["us-west-1", "eu-central-1"]

resource "aws_s3_bucket" "example" {
  region = "us-west-2"
}

policy "enforce_bucket_location" {
  mode = "soft-mandatory"
  enforcement_level = "advisory"

  rule "location" {
    level = "error"
    when  = awss3bucket.example.region != var.allowed_locations
    message = "El bucket está en una región no permitida"
  }
}

Capacidades clave

1. Modos de enforcement:

– soft-mandatory: falla el plan, pero puede overridearse con -target o -var-file.

– mandatory: bloquea el plan irrevocablemente.

1. Evaluación post-despliegue:

– Cambios realizados fuera de Terraform (drift).

– Recursos creados por otros tools (ej.: AWS Console, CloudFormation).

1. Data source lookups:

data "aws_vpc" "prod" {
  cidr_block = "10.0.0.0/16"
}

policy "no_overlapping_cidrs" {
  mode = "mandatory"

  rule "check_cidr" {
    level = "error"
    when  = contains([for s in data.aws_vpc.prod.cidr_block_associations : s.cidr_block], awsvpc.example.cidr_block)
    message = "La CIDR se superpone con la VPC de producción"
  }
}

1. Control de dependencias:

   policy "approved_providers" {
     mode = "mandatory"

     rule "trusted_sources" {
       level = "error"
       when  = contains(["hashicorp/", "aws/", "google/"], module.source)
       message = "El módulo no está en la lista de fuentes confiables"
     }
   }
   

Limitaciones actuales

• Integración completa solo en HCP Terraform: el CLI standalone (disponible para descarga) solo soporta validación y testing local, sin enforcement automático ni post-deploy checks.
• Coberturas iniciales: la beta pública incluye support para recursos de AWS, Google Cloud y Azure, pero la cobertura de attributes y data sources sigue expanding.
• Migración desde Sentinel: HashiCorp lanzó un AI agent (en preview) que puede convertir políticas de Sentinel a tfpolicy y generar nuevas políticas a partir de descripciones en natural language.

Qué deberían hacer los equipos técnicos

1. Evaluar la beta en entornos no productivos:

– Probar políticas simples contra infraestructura existente para validar la sintaxis y el comportamiento de los modes de enforcement.

1. Identificar políticas críticas para migrar:

– Dependan de relaciones entre recursos (ej.: «los security groups de las instancias deben permitir solo el tráfico desde el ALB»).

– Requieran contexto post-despliegue (ej.: «los buckets deben tener versioning enabled»).

– Controllen dependencias (proveedores/módulos).

– Usar el AI agent para convertir políticas existentes de Sentinel, pero revisar manualmente el resultado (la conversión no es perfecta).

1. Integrar tfpolicy en los workflows:

– Configurar policy sets a nivel de organization o workspace.

– Habiltar enforcement obligatorio para los modes mandatory y soft-mandatory.

– Usar terraform policy watch para monitoreo continuo.

– En workflows locales (con el CLI):

– Añadir terraform policy run al script de CI/CD, treating los errores como fallos en el pipeline.

1. Definir una estrategia de gobernanza:

– Establecer convenciones para el naming de políticas (ej.: security-, cost-, compliance-).

– Documentar excepciones y el proceso para solicitarlas.

1. Capacitar al equipo:

– La sintaxis de rules en tfpolicy.

– Cómo referenciar attributes y data sources en HCL.

– Los diferentes modes de enforcement.

Conclusión

tfpolicy representá un avance significativo para la gobernanza de infraestructura como código. Al eliminar la fricción de herramientas y languages separados, reduce la barrera de entrada para implementar Policy-as-Code, enabling a teams a codificar requerimientos de seguridad y cumplimiento junto con la infraestructura. Su integración nativa con Terraform y la capacidad de evaluar políticas post-despliegue abordan limitaciones clave de las soluciones existentes.

Sin embargo, la dependencia de HCP Terraform para las capacidades completas puede ser un punto de fricción para organizaciones que usan Terraform en modo open-source. A medida que madure la beta, será crucial evaluar si el valor agregado justifica la adopción del servicio managed.

Fuentes

• Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework