saltar al contenido
volver al mapa
técnica
etapa: definir
2 min de lectura

Policy as code

Una política escrita en un documento depende de que alguien la recuerde. Una política escrita como código se aplica en cada cambio, por igual para todos, y deja registro de lo que se decidió.

Open Policy AgentConftestKyvernoSentinel

Qué es

es expresar las reglas de la organización ("ningún bucket es público", "los contenedores no corren como root", "todo recurso tiene un responsable") en un lenguaje que una herramienta pueda evaluar automáticamente contra una entrada: un plan de Terraform, un manifiesto de Kubernetes, una solicitud de API.

La ganancia es consistencia y velocidad. La regla deja de depender de un revisor atento y pasa a ser un gate que responde en segundos, con un mensaje claro de por qué bloqueó.

Ejemplo en Rego (OPA)

usa el lenguaje Rego. La política de abajo evalúa el plan de Terraform y niega la creación de un bucket sin bloqueo de acceso público. Con Conftest, el mismo archivo corre en el CI sobre el plan exportado en JSON.

policy/s3.regorego
package terraform.s3

import rego.v1

deny contains msg if {
	r := input.resource_changes[_]
	r.type == "aws_s3_bucket_public_access_block"
	r.change.after.block_public_acls == false
	msg := sprintf("%s permite ACL pública", [r.address])
}

deny contains msg if {
	r := input.resource_changes[_]
	r.type == "aws_s3_bucket"
	not r.change.after.tags.owner
	msg := sprintf("%s sin etiqueta 'owner'", [r.address])
}

Dónde aplicarla

  • En el PR o en el CI: evaluar el plan de antes del merge (rápido y barato de corregir).
  • En la admisión del clúster: un controlador (Kyverno u OPA Gatekeeper) rechaza los objetos que violan la política en el momento en que llegan a la API.
  • En runtime y en la nube: reglas administradas y verificación continua detectan lo que se escapó o cambió después.
  • Las tres capas se complementan: el gate de CI da retroalimentación temprana; la admisión es la red de seguridad que nadie esquiva.

Probar la política como código

Una política sin pruebas es una suposición. OPA permite pruebas unitarias en Rego con casos que deben pasar y casos que deben negarse. Sin ellas, una regla puede dejar de detectar algo sin que nadie lo note o, en el otro extremo, bloquear cambios legítimos y llevar al equipo a desactivarla.

Excepciones y adopción gradual

Las excepciones existen, y lo importante es que sean explícitas, con responsable y plazo, y no huecos informales. Para adoptar sin bloquear a todos, empieza en modo de aviso (la política solo reporta), mide lo que se bloquearía, corrige el legado y solo entonces pasa a bloquear: la misma lógica de observación, shadow y enforcement que se usa en un .

Policy as codeOPA / RegoLa política de seguridad escrita como un archivo versionado que el pipeline consulta (denegar imagen con vulnerabilidad crítica, exigir firma). Cambia el criterio = cambia el archivo, con revisión.ver en el glosario →RegoOPALenguaje declarativo de Open Policy Agent para escribir políticas que se evalúan sobre una entrada (un plan de Terraform, un manifiesto de Kubernetes, una solicitud de API).ver en el glosario →IaCinfraestructura como códigoDescribir la infraestructura en archivos versionados (Terraform, Ansible). Aporta revisión, historial y pruebas a la configuración, pero replica errores a escala si no se escanea.ver en el glosario →WAFweb application firewallFiltro en el borde que bloquea patrones de ataque conocidos en HTTP. Complementa al código: no reemplaza corregir la vulnerabilidad, solo compra tiempo.ver en el glosario →

conexiones en el mapa

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

Estudia antes

Desbloquea

pon a prueba lo que entendiste

Cargando preguntas…