Gobernanza K8s multinube: Política como código con OPA/Kyverno
Kubernetes multi-nube sin Policy-as-Code será un riesgo NIS2 en 2026. OPA Gatekeeper y Kyverno impulsan el cumplimiento en el proceso de admisión.
Quien tenga una configuración multi-nube con tres o más clústeres de Kubernetes y documente la gobernanza aún en páginas de Confluence, corre un riesgo operativo en 2026 que los auditores NIS2 encontrarán a más tardar en la primera muestra. Policy-as-Code con OPA Gatekeeper o Kyverno empuja la aplicación de reglas al Admission-Path. Lo que antes vivía como PDF en la carpeta de cumplimiento se convierte en YAML, que verifica cada definición de Pod antes de que siquiera sea programada.
Lo más importante en resumen
- Policy-as-Code traslada el cumplimiento del momento de auditoría a la pipeline de compilación: OPA Gatekeeper y Kyverno se conectan como Admission-Webhook a cada llamada de API de Kubernetes y bloquean Pods que incumplen las especificaciones de configuración antes de que sean programados.
- Multi-nube significa múltiples motores de políticas o capa de plataforma unificada: EKS, AKS y GKE traen cada uno sus propias reglas por defecto. Quien quiera aplicar gobernanza consistentemente en todos los tres conjuntos de clústeres necesita un centro de políticas central o pipelines GitOps que empujen reglas idénticas a cada clúster.
- La diferencia entre OPA Gatekeeper y Kyverno es operativa, no ideológica: Gatekeeper necesita Rego como DSL y un equipo que domine de manera fiable el lenguaje. Kyverno funciona con patrones YAML que cualquier ingeniero de plataforma puede leer sin formación. La decisión casi siempre se reduce a la disponibilidad de habilidades, no a las listas de características.
Relacionado:Multi-Cluster sin nuevo silo Ops / Checklist de migración de Kubernetes 1.36
Por qué la deriva de cumplimiento en multi-nube K8s ocurre más rápido de lo que se piensa
En los artículos que hemos publicado en cloudmagazin desde principios de 2026, surge un patrón que la mayoría de los equipos de plataforma subestiman. Quien gestiona tres conjuntos de clústeres a través de EKS, AKS y GKE, eventualmente tendrá tres configuraciones por defecto ligeramente diferentes para los estándares de seguridad de Pods. Una pequeña desviación en la definición de `runAsNonRoot`, un comportamiento diferente con los tokens de cuenta de servicio automáticos, una ruta de valores por defecto diferente para las políticas de red. Individualmente, son inofensivos. En conjunto, crean un perfil de cumplimiento que ya nadie documenta completamente.
Las implementaciones de NIS2 sobre las que nuestros autores han escrito en las últimas semanas convierten exactamente esta brecha de deriva en un tema de auditoría. Ya no basta con mostrar que una política existe en algún lugar. Los auditores preguntan por el mecanismo que la aplica. Confluence no es una respuesta a eso.
Policy-as-Code con OPA Gatekeeper o Kyverno resuelve el problema al desplazar la definición de reglas al punto donde Kubernetes de todos modos verifica cada recurso. El Admission-Controller. Así, el cumplimiento se convierte en un paso de compilación, no en un evento trimestral.
OPA Gatekeeper vs. Kyverno: la línea operativa
Los comparativos teóricos de ambos motores se pueden encontrar en cada segunda grabación de conferencia de DevOps. En la práctica, las herramientas trazan otras líneas de lo que sugiere la matriz de características.
| Dimensión | OPA Gatekeeper | Kyverno |
|---|---|---|
| Lenguaje | Rego (DSL propia) | Patrones YAML, nativo de Kubernetes |
| Curva de aprendizaje | Empinada, conjunto de habilidades separado | Suave, familiar para ingenieros de plataforma |
| Políticas de mutación | A través del mutador de Gatekeeper | Incorporado |
| Reutilización fuera de K8s | Sí (patrones OPA en todas partes) | No (solo K8s) |
| Perfil de mejor ajuste | Equipos con experiencia en Rego, motor de cumplimiento en múltiples dominios | Equipos de plataforma que necesitan implementar gobernanza rápidamente |
Lo que en las migraciones de clúster de nuestras observaciones de autores siempre se revierte es la cuestión de habilidades. Rego es potente, pero si de ocho ingenieros de plataforma tres no pueden escribirlo productivamente, el mantenimiento de políticas se convierte en un cuello de botella. Kyverno alcanza el umbral de legibilidad antes.
Una configuración multi-nube sin desviación de políticas: cuatro pasos
- Versionar centralmente la biblioteca de políticas. Un único repositorio Git contiene todos los ConstraintTemplates o ClusterPolicies. Cada clúster es consumidor, ningún clúster es propietario. Quien mantenga políticas localmente por clúster, en seis meses tendrá tres definiciones diferentes para la misma regla.
- GitOps-Push en lugar de kubectl apply manual. Argo CD o Flux implementan la biblioteca de políticas en cada clúster. Así, el estado del clúster es una función del estado de Git, y las preguntas de auditoría se responden con un registro de Git en lugar de una captura de pantalla.
- Modo de auditoría antes que modo de aplicación. Las nuevas políticas se ejecutan al menos durante dos semanas en modo de advertencia. Los informes muestran qué cargas de trabajo existentes violarían la regla. Solo cuando la lista de infracciones esté vacía o se haya excluido deliberadamente, la política cambia a modo de bloqueo.
- Detección de desviación como capa separada. Incluso con GitOps hay cambios ad-hoc que pasan brevemente junto al controlador. Un informe semanal de desviación (por ejemplo, Argo-CD-Diff, Kyverno-Reports-API) muestra cualquier desviación. Sin esta capa, el estado multi-clúster se vuelve borroso con el tiempo.
Los primeros dos pasos son el programa obligatorio. El paso tres evita la trampa estándar en las que las políticas fallan en producción y bloque
Qué realmente deciden los equipos de plataforma en la elección de motores 2026
En las investigaciones que nuestros autores realizaron con responsables de plataformas DACH, surgieron tres anclas de decisión que rara vez aparecen en las diapositivas de las conferencias.
En primer lugar, la cuestión de si el equipo de plataforma ya aplica el cumplimiento para cargas de trabajo no Kubernetes (planes Terraform, políticas IAM, pipelines CI). Si es así, OPA es la palanca natural, ya que Rego cubre todas estas áreas. Si el mundo del cumplimiento es puramente Kubernetes, hay pocas razones para traer una segunda DSL a casa.
En segundo lugar, el tamaño y la distribución de senioridad en el equipo. Un equipo de tres ingenieros, donde solo uno escribe fiablemente en Rego, está mejor servido con Kyverno. Tan pronto como ese ingeniero está de vacaciones o renuncia, el mantenimiento de las políticas se detiene. Los archivos YAML de Kyverno sobreviven a la fluctuación de personal de manera mucho más relajada.
En tercer lugar, el software de seguridad existente. Quien ya tiene Falco, Trivy o estándares de seguridad de Pod en su pipeline, a menudo tiene expectativas de informes que Kyverno cumple de forma nativa con los CRDS de informes. Gatekeeper ofrece menos aquí «out of the box».
Preguntas frecuentes
¿Vale la pena Policy-as-Code ya con un único clúster de Kubernetes?
Sí, tan pronto como el clúster soporta cargas de producción de más de un equipo. Sin controladores de admisión, la responsabilidad de la consistencia migra a cada manifiesto individual. Con Policy-as-Code se convierte en una característica de la plataforma. En un clúster de laboratorio, el sobrecargo es demasiado grande, en una configuración multiinquilino es obligatorio.
¿Cuál es el sobrecargo de rendimiento debido a los webhooks de admisión?
En configuraciones bien establecidas, la contribución adicional de latencia de admisión se encuentra en el rango de los dígitos de milisegundos por creación de Pod. Solo se vuelve crítico en operaciones masivas (por ejemplo, lanzamientos de Helm con cientos de recursos) o con plantillas de restricción muy complejas. Ambos motores soportan caché y reconciliación en segundo plano.
¿Pueden OPA y Kyverno ejecutarse en paralelo en el mismo clúster?
Técnicamente sí, ambos se registran como webhooks diferentes. Operativamente rara vez tiene sentido. Las políticas duplicadas causan confusión en la depuración, las capas de auditoría duplican el mantenimiento. Si es necesario un camino de migración, ejecútelos en paralelo, de lo contrario, consolídense en un solo motor.
¿Qué pasa si el webhook de admisión falla?
Depende de la configuración de `failurePolicy`. Con `Fail`, cada fallo del webhook bloquea el clúster para nuevos Pods. Con `Ignore`, las políticas se omiten cuando el webhook cae, lo que en el peor caso crea lagunas de cumplimiento. La mejor práctica para producción es `Fail` más alta disponibilidad de los despliegues del webhook. Una configuración de un solo Pod para un clúster multiinquilino es negligente.
¿Es suficiente Policy-as-Code para el cumplimiento NIS2 por sí solo?
No, pero cubre una gran parte de las obligaciones técnicas de prueba. NIS2 también requiere procesos de respuesta a incidentes, gestión de proveedores y generación de informes. Policy-as-Code proporciona la prueba técnica para la aplicación de configuraciones de seguridad, lo que reduce significativamente la carga de auditoría. El aspecto organizativo permanece sin afectar.
