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ó.
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.
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 .
conexiones en el mapa
- Infraestructura segura como códigoes validado porPolicy as code
- Policy as codese vuelve un gateHardening de CI/CD
- La seguridad como producto internoentrega como camino pavimentadoPolicy as code
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Cumplimiento en la práctica: controles, evidencias y auditoríasgrcla evidencia automática nace de políticas ejecutables
- DevSecOpsappsecgates y políticas, escritos como código ejecutable
Estudia antes
Desbloquea
pon a prueba lo que entendiste
Cargando preguntas…