Testing de Policy as Code: OPA vs Sentinel en 2026

TL;DR

• OPA es tu opcion para enforcement de policies multiplataforma (Kubernetes, Terraform, APIs); Sentinel sobresale en el ecosistema HashiCorp
• Los tests de policies son codigo — escribelos antes de la policy usando el framework de testing integrado de OPA
• El error #1: tratar policies como documentacion en lugar de codigo testeado y versionado

Ideal para: Equipos gestionando infraestructura en multiples nubes o plataformas que necesitan gobernanza unificada Omite si: Estas 100% en Terraform Cloud/Enterprise y nunca tocas Kubernetes Tiempo de lectura: 11 minutos

Tu plan de Terraform paso todos los tests. CI esta verde. Haces merge y deploy. Tres horas despues, alguien provisiona un bucket S3 publicamente accesible sin encriptacion. Tu equipo de seguridad esta furioso.

El problema no son tus tests — es que estas testeando la capa equivocada. Los tests de infraestructura verifican que se despliega. Los tests de policies verifican que esta permitido desplegar. En 2026, con herramientas de IA generando configs de Terraform mas rapido que nunca, esta distincion es critica.

El Problema Real

La mayoria de equipos abordan policy as code al reves. Escriben policies despues de incidentes, las guardan en una wiki y esperan que los desarrolladores las lean. Esto es policy como documentacion, no policy como codigo.

Policy as code real significa:

• Policies versionadas en Git junto con la infraestructura
• Policies con tests unitarios que corren en CI
• Policies que bloquean deployments automaticamente, no via comentarios en code review
• Violaciones de policies producen mensajes de error accionables, no fallos cripticos

El cambio de “guias” a “guardarrailes” requiere un cambio de modelo mental. No estas escribiendo reglas para que humanos sigan — estas escribiendo restricciones ejecutables que las maquinas enforzan.

OPA vs Sentinel: La Realidad 2026

Open Policy Agent (OPA) v1.9.0 y HashiCorp Sentinel ambos resuelven enforcement de policies, pero sus alcances difieren dramaticamente.

Mi recomendacion: Comienza con OPA si trabajas en multiples plataformas o valoras la portabilidad. Elige Sentinel si estas profundamente invertido en HashiCorp Cloud Platform y quieres integracion estrecha sin pasos de transformacion.

Escribiendo Policies OPA Testeables

El insight clave es que las policies deben escribirse test-first. Antes de codificar la policy, define que debe pasar y que debe fallar.

package terraform.aws.s3

import rego.v1

# Denegar buckets S3 sin encriptacion
deny contains msg if {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_s3_bucket"
    not has_encryption(resource)
    msg := sprintf("S3 bucket '%s' must have server-side encryption enabled", [resource.name])
}

has_encryption(bucket) if {
    bucket.values.server_side_encryption_configuration[_].rule[_].apply_server_side_encryption_by_default[_].sse_algorithm
}

Nota el import rego.v1 — esta es la sintaxis moderna de OPA v1.x. La palabra clave contains y los guards if son convenciones de Rego v1 que reemplazan la generacion implicita de sets anterior.

Testeando Tus Policies

El framework de testing de OPA te permite verificar el comportamiento de policies antes del deployment. Crea un archivo de test junto a tu policy:

package terraform.aws.s3_test

import data.terraform.aws.s3

# Test: Bucket encriptado debe ser permitido
test_encrypted_bucket_allowed if {
    count(s3.deny) == 0 with input as {
        "planned_values": {
            "root_module": {
                "resources": [{
                    "type": "aws_s3_bucket",
                    "name": "secure_bucket",
                    "values": {
                        "server_side_encryption_configuration": [{
                            "rule": [{
                                "apply_server_side_encryption_by_default": [{
                                    "sse_algorithm": "AES256"
                                }]
                            }]
                        }]
                    }
                }]
            }
        }
    }
}

# Test: Bucket sin encriptacion debe ser denegado
test_unencrypted_bucket_denied if {
    count(s3.deny) > 0 with input as {
        "planned_values": {
            "root_module": {
                "resources": [{
                    "type": "aws_s3_bucket",
                    "name": "insecure_bucket",
                    "values": {}
                }]
            }
        }
    }
}

Ejecuta tests con opa test . -v para ver output detallado. El flag -v muestra que tests pasaron y cuales fallaron con razones.

Integracion CI/CD

El workflow para Terraform + OPA en tu pipeline:

# 1. Generar plan
terraform plan -out=tfplan.binary

# 2. Convertir a JSON para OPA
terraform show -json tfplan.binary > tfplan.json

# 3. Evaluar policies
opa exec --decision terraform/aws/s3/deny --bundle policies/ tfplan.json

# 4. Fallar si existen violaciones
if [ $(opa eval -d policies/ -i tfplan.json 'data.terraform.aws.s3.deny' | jq '.result[0].expressions[0].value | length') -gt 0 ]; then
    echo "Policy violations detected!"
    exit 1
fi

Para Conftest (herramienta dedicada de OPA para testing de archivos de config), la sintaxis es mas simple:

conftest test tfplan.json --policy policies/

Conftest automaticamente busca reglas deny y sale con codigo no-cero si alguna dispara.

Sentinel para Terraform Cloud

Si usas Terraform Cloud o Enterprise, Sentinel ofrece integracion mas estrecha. La policy equivalente de encriptacion S3:

import "tfplan/v2" as tfplan

s3_buckets = filter tfplan.resource_changes as _, rc {
    rc.type is "aws_s3_bucket" and
    rc.mode is "managed" and
    (rc.change.actions contains "create" or rc.change.actions contains "update")
}

encryption_required = rule {
    all s3_buckets as _, bucket {
        bucket.change.after.server_side_encryption_configuration is not null
    }
}

main = rule {
    encryption_required
}

El import tfplan/v2 de Sentinel te da acceso nativo a la estructura del plan de Terraform sin conversion JSON. Los niveles de enforcement (advisory, soft-mandatory, hard-mandatory) te permiten desplegar policies gradualmente.

Enfoques Asistidos por IA

Escribir policies en Rego o Sentinel requiere aprender un nuevo lenguaje. En 2026, las herramientas de IA aceleran significativamente este proceso.

Lo que la IA hace bien:

• Generar borradores iniciales de policies desde requerimientos en lenguaje natural
• Convertir entre sintaxis OPA y Sentinel
• Crear casos de test comprensivos para condiciones edge
• Explicar comprehensiones complejas de Rego

Lo que aun necesita humanos:

• Decidir que recursos requieren que restricciones
• Establecer niveles de severidad apropiados para violaciones
• Revisar policies generadas por IA para correccion logica
• Entender el contexto de negocio detras de requerimientos de compliance

Prompt util:

Escribe una policy OPA Rego que:
1. Deniegue instancias AWS EC2 sin el tag "Environment"
2. Permita excepciones para instancias con "temporary: true" en metadata
3. Incluya tests unitarios comprensivos para ambos casos
4. Use sintaxis Rego v1 con imports explicitos

Cuando Esto Falla

Policy as code tiene limitaciones:

Explosion de complejidad: A medida que las policies crecen, las interdependencias se vuelven dificiles de rastrear. Una policy permitiendo instancias t3.micro conflictua con una policy requiriendo volumenes EBS encriptados en ciertos tipos de instancia.

Falsos positivos: Policies demasiado estrictas bloquean casos de uso legitimos. Los equipos empiezan a pedir excepciones, y terminas con una policy llena de excepciones.

Performance a escala: Evaluar miles de policies contra planes Terraform grandes puede ralentizar CI significativamente. OPA maneja esto bien con evaluacion parcial, pero necesitas optimizar.

Drift entre policy y realidad: Las policies enforzan lo que esta planeado, no lo que esta corriendo. Un recurso creado manualmente bypasea todos los policy checks.

Considera herramientas complementarias:

• Deteccion de drift en Terraform para recursos existentes
• Herramientas cloud-nativas (AWS Config, Azure Policy) para enforcement en runtime
• Compliance testing para IaC para requerimientos regulatorios

Framework de Decision

Elige OPA cuando:

• Gestionas Kubernetes junto con Terraform
• Necesitas policies para autorizacion de API o CI/CD gates
• Tu infraestructura abarca multiples nubes
• Restricciones de presupuesto descartan Terraform Enterprise

Elige Sentinel cuando:

• Estas all-in en HashiCorp Cloud Platform
• Quieres niveles de enforcement sin construir logica CI custom
• Tu equipo ya conoce Sentinel de Vault o Nomad
• Necesitas soporte first-class y SLAs

Usa ambos cuando:

• OPA para Kubernetes admission control (Gatekeeper)
• Sentinel para gobernanza especifica de Terraform en TFC

Midiendo el Exito

Senales de alarma de que no esta funcionando:

• Equipos bypaseando CI para evitar policy checks
• Lista creciente de excepciones permanentes
• Policies que nunca disparan (muy permisivas)
• Policies bloqueando cada PR (muy estrictas)

Que Sigue

Empieza pequeno. Elige una policy de alto impacto — quizas encriptacion S3 o tagging de instancias — e implementala end-to-end:

1. Escribe la policy con tests
2. Anade a CI como warning (modo advisory)
3. Monitorea falsos positivos por un sprint
4. Promueve a bloqueante (modo mandatory)
5. Expande a la siguiente policy

El objetivo no es 100% cobertura de policy el dia uno. Es construir memoria muscular para tratar policies como codigo de produccion.

Articulos relacionados:

• Estrategias de Testing y Validacion de Terraform
• Testing de Infrastructure as Code
• Workflows GitOps para QA y Testing
• Compliance Testing para IaC

Recursos externos:

• Documentacion OPA
• Documentacion Sentinel
• Conftest