Open Policy Agent para MSP: admisión, autorización de API y puertas de CI

Open Policy Agent (OPA) es conocido sobre todo como el motor detrás del control de admisión de Kubernetes, pero el proyecto principal no tiene nada específico de Kubernetes. Esta guía es para MSP y equipos de plataforma que quieren usar OPA como motor de políticas de propósito general —para autorización de API, controles de CI y admisión en Kubernetes— sin confundir qué hace cada herramienta, además de lo que cambió en una corrección reciente del parser para quienes ya usan la nueva sintaxis Rego de OPA.

Dónde encaja OPA más allá de Kubernetes

El proyecto principal —open-policy-agent/opa en GitHub, con unas 12,3 mil estrellas y 1,7 mil forks— es un motor de políticas que evalúa una solicitud frente a una política escrita en lugar de lógica de aplicación codificada de forma fija. Los MSP y los equipos de producto lo usan en cualquier lugar donde deba tomarse ese tipo de decisión, no solo en el borde de un clúster de Kubernetes.

El mismo lenguaje de políticas Rego que ejecuta funciona igual de bien en una puerta de enlace de API o dentro de un sidecar de servicio, evaluando si una solicitud está autorizada antes de que llegue al código de la aplicación. Los mismos paquetes de políticas se pueden reutilizar en pipelines de CI para detectar violaciones, como una dependencia prohibida, un recurso mal configurado o una región no aprobada, antes de que se despliegue un cambio en lugar de después.

OPA, Gatekeeper y Conftest son tres cosas distintas

El control de admisión de Kubernetes mediante Gatekeeper es una integración construida sobre OPA, no OPA en sí, y Conftest es una herramienta de línea de comandos independiente para probar archivos de configuración estructurados frente a políticas Rego. Reunir las tres en una única historia de OPA en material de cara al cliente exagera lo que hace cada herramienta por sí sola: cada una tiene su propio modelo de despliegue y sus propios modos de fallo.

Gatekeeper: aplicar políticas en la puerta de entrada de Kubernetes

OPA Gatekeeper, mantenido bajo la organización Open Policy Agent en GitHub con unas 4,3 mil estrellas, es un controlador de admisión de Kubernetes. Intercepta las solicitudes a la API mediante un webhook de admisión de validación y las verifica frente a políticas Rego en el momento en que se envía una carga de trabajo, en lugar de después de que ya esté en ejecución. Para un MSP que gestiona varios clústeres de clientes, una regla se puede escribir una vez y aplicarse de forma coherente: exigir que las imágenes de contenedor procedan de un registro aprobado o lleven una atestación de firma verificada, denegar contenedores que soliciten modo privilegiado o montajes hostPath sin restricciones, o restringir qué tipos de carga de trabajo puede aceptar un espacio de nombres determinado.

Gatekeeper es una integración específica de Kubernetes, no un sustituto del motor principal, que los MSP también usan para autorización de API y controles de CI fuera de Kubernetes; ambos son complementarios, con Gatekeeper a cargo de la vía de admisión mientras el motor principal toma decisiones de política en otras partes de la pila. Tampoco sustituye a RBAC, la política de red o la higiene de secretos: añade una capa sobre ellos, no en su lugar.

Septiembre de 2026: un error del parser corregido en OPA 1.20.2

OPA 1.20.2, publicada a principios de septiembre de 2026, corrige un error del parser introducido dos versiones antes en la 1.20.0, que había añadido las nuevas palabras clave Rego and y or para combinar condiciones dentro de un mismo cuerpo de regla. Cuando una política importaba esas palabras clave, directamente o mediante import future.keywords, el parser de OPA primero leía una instrucción que empezaba con una llave como cuerpo de un operando y luego la releía como un término, como una comprensión, si no seguía ni and ni or.

Una regresión hacía que los errores registrados durante esa primera lectura abandonada quedaran en caché y se reportaran por error en la segunda lectura, la exitosa, lo que provocaba que el parser rechazara políticas que en realidad eran válidas. Las políticas que no importan and/or nunca se vieron afectadas, y se trata de una corrección puntual, no de un aviso de seguridad; el proyecto complementario opa-envoy-plugin publicó una versión v1.20.2-envoy correspondiente, así que los equipos que usan ese plugin deberían confirmar que recibieron la misma actualización de versión.

Los MSP que quieran una verificación externa de estos controles como parte de un programa de cumplimiento NIS2, DORA o RGPD pueden apoyarse en soporte dedicado: los servicios de ciberseguridad de Altovar cubren pruebas de penetración, evaluación de vulnerabilidades, respuesta a incidentes y trabajo de cumplimiento para esos mismos marcos.

Puntos de partida prácticos

• Autorización de API: evalúa políticas Rego en la capa de la puerta de enlace o el sidecar para solicitudes que necesiten reglas por tenant o por rol más allá de la autenticación integrada de un framework.
• Puertas de política en CI: ejecuta las mismas reglas Rego contra infraestructura como código o manifiestos en un paso del pipeline, fallando el build ante violaciones en lugar de depender de revisión manual.
• Admisión en Kubernetes: inicia las políticas de Gatekeeper en modo dry-run o warn, documenta excepciones para cargas de trabajo existentes y limita las restricciones a espacios de nombres específicos antes de ampliarlas.
• Bibliotecas de políticas compartidas: escribe las reglas una vez y aplícalas en admisión, autorización de API y CI en lugar de reimplementar la misma lógica tres veces.

Qué hacer

1. Mapea dónde viven hoy las decisiones de política en tu pila —admisión, gateway, CI— y señala las que siguen codificadas de forma fija en lugar de basarse en políticas.
2. Si usas Gatekeeper, despliega las restricciones nuevas en modo dry-run o warn y documenta las excepciones antes de pasar a enforce.
3. Mantén las tres herramientas separadas en tu propia documentación: el motor OPA, Gatekeeper para admisión y Conftest para CI y pruebas de configuración.
4. Si tus políticas Rego importan las palabras clave and/or, confirma que estás en la versión 1.20.2 o posterior antes de tratar un rechazo como un error de redacción.
5. Comprueba si herramientas dependientes, como el plugin de Envoy o los sidecars, recibieron la misma actualización de versión de OPA.
6. Combina las políticas de admisión y autorización con RBAC, política de red e higiene de secretos, en lugar de tratarlas como un sustituto completo.

Fuentes: GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.