Los pipelines de CI\/CD modernos se mueven r\u00e1pido. Los equipos realizan decenas \u2014 a veces cientos \u2014 de despliegues por d\u00eda, y cada uno de esos despliegues conlleva decisiones de configuraci\u00f3n que afectan la seguridad, el cumplimiento normativo y la estabilidad operativa. Un solo manifiesto de Kubernetes mal configurado, un rol de IAM con permisos excesivos en Terraform, o una imagen de contenedor descargada de un registro no confiable pueden exponer toda tu infraestructura.<\/p>\n
Las revisiones manuales de c\u00f3digo no pueden mantener el ritmo. Incluso el ingeniero de seguridad m\u00e1s diligente pasar\u00e1 por alto cosas al revisar cientos de pull requests por semana. Aqu\u00ed es donde entran los motores de pol\u00edticas<\/strong>: herramientas automatizadas que eval\u00faan la infraestructura como c\u00f3digo, los manifiestos de despliegue y las configuraciones de pipelines contra un conjunto declarativo de reglas \u2014 y bloquean las violaciones antes de que lleguen a producci\u00f3n.<\/p>\n Los motores de pol\u00edticas transforman la seguridad de un cuello de botella en una barrera de protecci\u00f3n. En lugar de ralentizar a los desarrolladores con puertas de aprobaci\u00f3n manuales, proporcionan retroalimentaci\u00f3n instant\u00e1nea y determinista en el propio pipeline de CI. \u00bfUn desarrollador env\u00eda un plan de Terraform que otorga permisos Pero el panorama de los motores de pol\u00edticas ha crecido r\u00e1pidamente, y elegir el correcto \u2014 o la combinaci\u00f3n correcta \u2014 no es sencillo. En esta gu\u00eda, comparamos cuatro motores de pol\u00edticas l\u00edderes: Open Policy Agent (OPA)<\/strong>, Kyverno<\/strong>, HashiCorp Sentinel<\/strong> y AWS Cedar<\/strong>. Examinaremos cada uno en profundidad, los compararemos en las dimensiones que m\u00e1s importan para la seguridad de CI\/CD, y proporcionaremos una matriz de decisi\u00f3n para ayudarte a elegir.<\/p>\n Open Policy Agent (OPA)<\/a> es el motor de pol\u00edticas de prop\u00f3sito general m\u00e1s establecido en el ecosistema cloud-native. Creado originalmente por Styra y donado a la Cloud Native Computing Foundation (CNCF), OPA se gradu\u00f3 como proyecto CNCF en 2021. Est\u00e1 dise\u00f1ado para desacoplar las decisiones de pol\u00edticas de la l\u00f3gica de la aplicaci\u00f3n, proporcionando un motor ligero y de alto rendimiento que puede integrarse como sidecar, biblioteca o demonio independiente.<\/p>\n OPA utiliza Rego<\/strong>, un lenguaje de consulta declarativo de prop\u00f3sito espec\u00edfico inspirado en Datalog. Las pol\u00edticas de Rego operan sobre datos estructurados (JSON\/YAML), lo que las hace aplicables a pr\u00e1cticamente cualquier dominio: control de admisi\u00f3n de Kubernetes, validaci\u00f3n de planes de Terraform, autorizaci\u00f3n de APIs, aplicaci\u00f3n de pol\u00edticas en pipelines de CI\/CD, y m\u00e1s.<\/p>\n Rego es potente pero tiene una curva de aprendizaje real. Es un lenguaje de programaci\u00f3n l\u00f3gica donde se definen reglas como declaraciones l\u00f3gicas en lugar de instrucciones imperativas. Aqu\u00ed hay un ejemplo simple que deniega contenedores que se ejecutan como root:<\/p>\n El estilo declarativo es elegante una vez que lo internalizas, pero los desarrolladores acostumbrados a lenguajes imperativos a menudo tienen dificultades con el modelo de evaluaci\u00f3n de Rego \u2014 particularmente con la evaluaci\u00f3n parcial, la comprensi\u00f3n de conjuntos y la iteraci\u00f3n impl\u00edcita sobre colecciones usando la sintaxis Conftest<\/a> es la respuesta de OPA para la integraci\u00f3n con CI\/CD. Es una herramienta de l\u00ednea de comandos que ejecuta pol\u00edticas de OPA contra archivos de configuraci\u00f3n estructurados \u2014 YAML de Kubernetes, planes de Terraform, Dockerfiles y m\u00e1s. Un paso t\u00edpico en CI se ve as\u00ed:<\/p>\n Conftest soporta m\u00faltiples formatos de entrada de forma nativa, puede descargar pol\u00edticas desde registros OCI (permitiendo la distribuci\u00f3n centralizada de pol\u00edticas) y se integra limpiamente en cualquier sistema de CI que pueda ejecutar un comando de shell. Para un recorrido pr\u00e1ctico, consulta nuestro Laboratorio: Aplicaci\u00f3n de Pol\u00edticas de Despliegue de Kubernetes con OPA Conftest en CI\/CD<\/a>.<\/p>\n Para una gu\u00eda completa sobre OPA y Rego en CI\/CD, consulta nuestro art\u00edculo: Pol\u00edticas como C\u00f3digo para CI\/CD: Aplicaci\u00f3n de Puertas de Seguridad con OPA y Rego<\/a>.<\/p>\n Kyverno<\/a> es un motor de pol\u00edticas nativo de Kubernetes que fue dise\u00f1ado espec\u00edficamente para el ecosistema Kubernetes. Se convirti\u00f3 en un proyecto incubado de CNCF y ha experimentado una adopci\u00f3n r\u00e1pida entre equipos que desean aplicaci\u00f3n de pol\u00edticas sin aprender un nuevo lenguaje de programaci\u00f3n. La filosof\u00eda central de Kyverno es que los administradores de Kubernetes deber\u00edan poder escribir pol\u00edticas usando el mismo YAML que ya conocen.<\/p>\n Las pol\u00edticas de Kyverno se definen como recursos personalizados de Kubernetes. No hay un nuevo lenguaje que aprender \u2014 las pol\u00edticas usan la sintaxis YAML familiar con coincidencia de patrones, overlays y expresiones JMESPath para condiciones. Aqu\u00ed hay una pol\u00edtica equivalente que requiere que los contenedores se ejecuten como no-root:<\/p>\n Este enfoque YAML-first reduce dr\u00e1sticamente la barrera de entrada. Cualquier operador de Kubernetes puede leer y escribir pol\u00edticas de Kyverno sin formaci\u00f3n especializada.<\/p>\n Kyverno se ha expandido m\u00e1s all\u00e1 del control de admisi\u00f3n puro con el Kyverno CLI<\/strong>, que puede validar recursos contra pol\u00edticas de forma offline \u2014 haci\u00e9ndolo utilizable en pipelines de CI\/CD:<\/p>\n El CLI soporta pruebas de pol\u00edticas, validaci\u00f3n de recursos y puede generar informes JUnit XML para integraci\u00f3n con CI. Sin embargo, la historia de CI\/CD de Kyverno es m\u00e1s limitada que la de OPA: funciona mejor con manifiestos de Kubernetes y no maneja de forma nativa planes de Terraform, Dockerfiles u otros formatos que no sean de Kubernetes.<\/p>\n HashiCorp Sentinel<\/a> es un framework de pol\u00edticas como c\u00f3digo integrado en los productos comerciales de HashiCorp: Terraform Cloud\/Enterprise, Vault Enterprise, Consul Enterprise y Nomad Enterprise. Fue dise\u00f1ado espec\u00edficamente para proporcionar barreras de gobernanza para flujos de trabajo de aprovisionamiento de infraestructura.<\/p>\n Sentinel utiliza su propio lenguaje de dominio espec\u00edfico que es m\u00e1s imperativo que Rego y m\u00e1s accesible para desarrolladores familiarizados con Python o Go. Aqu\u00ed hay un ejemplo que restringe los tipos de instancias EC2 en Terraform:<\/p>\n El lenguaje soporta importaciones, funciones, niveles de aplicaci\u00f3n (advisory, soft-mandatory, hard-mandatory) y tiene una sensaci\u00f3n imperativa familiar. Las pol\u00edticas se leen de forma m\u00e1s natural que Rego para la mayor\u00eda de los desarrolladores.<\/p>\n Sentinel est\u00e1 profundamente integrado en los flujos de trabajo de Terraform Cloud y Enterprise. Las pol\u00edticas se eval\u00faan autom\u00e1ticamente durante Para pipelines de CI\/CD fuera del ecosistema HashiCorp, el Sentinel CLI<\/strong> (el simulador Cedar<\/a> es un lenguaje de pol\u00edticas y motor de evaluaci\u00f3n desarrollado por AWS y liberado como c\u00f3digo abierto en 2023. Originalmente construido para potenciar Amazon Verified Permissions y AWS IAM Identity Center, Cedar fue dise\u00f1ado desde cero para la autorizaci\u00f3n<\/strong> \u2014 determinar si un principal puede realizar una acci\u00f3n sobre un recurso.<\/p>\n Cedar es el participante m\u00e1s reciente en esta comparativa, y su enfoque tiene un alcance m\u00e1s limitado que OPA o Kyverno. Si bien sobresale en decisiones de autorizaci\u00f3n de grano fino, su aplicaci\u00f3n a la aplicaci\u00f3n de pol\u00edticas en CI\/CD a\u00fan est\u00e1 en desarrollo.<\/p>\n El lenguaje de Cedar prioriza la legibilidad y la capacidad de an\u00e1lisis. Las pol\u00edticas se expresan como declaraciones permit\/forbid que se leen casi como ingl\u00e9s:<\/p>\n El sistema de tipos y las capacidades de verificaci\u00f3n formal de Cedar son \u00fanicos entre los motores en esta comparativa. AWS ha publicado pruebas formales<\/a> de propiedades clave del lenguaje Cedar, asegurando que las pol\u00edticas se comporten de manera predecible y puedan analizarse en busca de conflictos, redundancias y completitud.<\/p>\n La historia de integraci\u00f3n de Cedar con CI\/CD es la menos madura de los cuatro motores. Puede usarse para modelar decisiones de autorizaci\u00f3n en CI\/CD \u2014 por ejemplo, qui\u00e9n puede desplegar en qu\u00e9 entorno, qu\u00e9 pipelines pueden acceder a qu\u00e9 secretos, o qu\u00e9 ramas pueden activar releases en producci\u00f3n \u2014 pero requiere trabajo de integraci\u00f3n personalizado. No existe un equivalente a Conftest o al Kyverno CLI para validar manifiestos de Kubernetes o planes de Terraform contra pol\u00edticas de Cedar de forma nativa.<\/p>\n Dicho esto, el SDK de Cedar est\u00e1 disponible en Rust, Java y Go, y su motor de evaluaci\u00f3n puede integrarse en herramientas de CI\/CD personalizadas. Los equipos que construyen plataformas de despliegue a medida en AWS pueden encontrar en Cedar una opci\u00f3n natural para la l\u00f3gica de autorizaci\u00f3n.<\/p>\ns3:*<\/code>? El pipeline falla con un mensaje claro explicando por qu\u00e9. \u00bfUn manifiesto de Kubernetes ejecuta un contenedor como root? Bloqueado antes de que llegue al cl\u00faster.<\/p>\nOpen Policy Agent (OPA) y Rego<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Lenguaje de Pol\u00edticas: Rego<\/h3>\n
package kubernetes.admission\n\ndeny[msg] {\n input.request.kind.kind == \"Pod\"\n container := input.request.object.spec.containers[_]\n container.securityContext.runAsUser == 0\n msg := sprintf(\"Container '%v' must not run as root\", [container.name])\n}<\/code><\/pre>\n[_]<\/code>.<\/p>\nIntegraci\u00f3n con CI\/CD mediante Conftest<\/h3>\n
conftest test deployment.yaml --policy .\/policies\/ --output json<\/code><\/pre>\nFortalezas<\/h3>\n
\n
opa test<\/code>, incluyendo an\u00e1lisis de cobertura.<\/li>\nDebilidades<\/h3>\n
\n
Kyverno<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Lenguaje de Pol\u00edticas: YAML (Nativo de Kubernetes)<\/h3>\n
apiVersion: kyverno.io\/v1\nkind: ClusterPolicy\nmetadata:\n name: require-run-as-nonroot\nspec:\n validationFailureAction: Enforce\n rules:\n - name: check-containers\n match:\n any:\n - resources:\n kinds:\n - Pod\n validate:\n message: \"Containers must not run as root\"\n pattern:\n spec:\n containers:\n - securityContext:\n runAsNonRoot: true<\/code><\/pre>\nIntegraci\u00f3n con CI\/CD<\/h3>\n
kyverno apply .\/policies\/ --resource deployment.yaml<\/code><\/pre>\nFortalezas<\/h3>\n
\n
Debilidades<\/h3>\n
\n
HashiCorp Sentinel<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Lenguaje de Pol\u00edticas: Lenguaje Sentinel<\/h3>\n
import \"tfplan\/v2\" as tfplan\n\nallowed_instance_types = [\"t3.micro\", \"t3.small\", \"t3.medium\"]\n\nmain = rule {\n all tfplan.resource_changes as _, rc {\n rc.type is \"aws_instance\" implies\n rc.change.after.instance_type in allowed_instance_types\n }\n}<\/code><\/pre>\nIntegraci\u00f3n con CI\/CD<\/h3>\n
terraform plan<\/code> en Terraform Cloud, y los niveles de aplicaci\u00f3n determinan si las violaciones producen advertencias o bloquean los applies. Esta estrecha integraci\u00f3n es tanto la mayor fortaleza como la principal limitaci\u00f3n de Sentinel.<\/p>\nsentinel<\/code>) permite pruebas y evaluaci\u00f3n local, pero opera contra datos simulados en lugar del estado de infraestructura en vivo. Puedes probar pol\u00edticas de Sentinel en un pipeline de CI, pero el punto principal de aplicaci\u00f3n est\u00e1 dentro de los propios productos de HashiCorp.<\/p>\nFortalezas<\/h3>\n
\n
Debilidades<\/h3>\n
\n
AWS Cedar<\/h2>\n
Descripci\u00f3n General<\/h3>\n
Lenguaje de Pol\u00edticas: Cedar<\/h3>\n
\/\/ Only allow production deployments from the main branch\nforbid (\n principal,\n action == Action::\"deploy\",\n resource == Environment::\"production\"\n) unless {\n context.source_branch == \"main\" &&\n context.tests_passed == true &&\n context.approvals >= 2\n};<\/code><\/pre>\nIntegraci\u00f3n con CI\/CD<\/h3>\n
Fortalezas<\/h3>\n
\n
Debilidades<\/h3>\n
\n
Tabla Comparativa<\/h2>\n