GitOps con Argo CD y Kyverno: políticas Kubernetes en serio
Una guía reciente de la CNCF muestra cómo integrar Argo CD y Kyverno para aplicar políticas de seguridad como código, con despliegues auditables, transición controlada entre modo Audit y Enforce, y menor riesgo de configuración insegura en producción.
Introducción
En entornos Kubernetes maduros, el problema ya no suele ser «cómo desplegar más rápido», sino cómo hacerlo sin degradar seguridad y compliance en cada cambio. Durante años, muchos equipos resolvieron esto con revisiones manuales o controles dispersos por pipeline. El resultado habitual: reglas inconsistentes entre clusters, excepciones difíciles de auditar y políticas aplicadas tarde, cuando el recurso ya estaba en producción.
La publicación de CNCF del 2 de abril de 2026 sobre GitOps policy-as-code vuelve a poner el foco en una práctica que viene ganando tracción: tratar las políticas de plataforma con el mismo rigor que el código de infraestructura. La propuesta combina Argo CD como motor GitOps y Kyverno como motor de políticas nativas de Kubernetes.
Qué ocurrió
El nuevo artículo técnico de CNCF describe un enfoque práctico para desplegar Kyverno junto con Argo CD usando patrón App-of-Apps. La guía no se queda en teoría: plantea estructura de repositorio, orden de sincronización entre aplicaciones, uso de charts oficiales y estrategias para introducir políticas sin romper workloads existentes.
El flujo recomendado comienza con políticas en modo Audit para observar incumplimientos sin bloquear despliegues, y luego migra gradualmente a Enforce cuando el equipo tiene evidencia suficiente para endurecer controles.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma y SRE, el impacto principal es operativo: centralizar gobernanza sin volver más lenta la entrega. Argo CD ya versiona y sincroniza manifiestos desde Git; Kyverno añade una capa de admisión que valida, muta, genera o limpia recursos según políticas declarativas en YAML.
Esto reduce el «drift» entre lo que se aprueba en diseño y lo que realmente entra al cluster. También facilita auditorías porque cada cambio de política deja trazabilidad en Git, PR y historial de sincronización.
En seguridad, el valor más inmediato es bloquear patrones de riesgo conocidos (por ejemplo, uso indebido de externalIPs, una superficie históricamente asociada a ataques tipo MITM como CVE-2020-8554) y estandarizar baseline por namespace o por tipo de workload.
Detalles técnicos
La guía de CNCF propone instalar primero Kyverno y luego el paquete de políticas, ordenado por sync-wave en Argo CD. Ese detalle evita condiciones de carrera: no tiene sentido aplicar políticas si el admission controller aún no está listo.
También recomienda opciones de sincronización concretas en Argo CD, como ServerSideApply=true y configuración de comparación para contemplar mutaciones del webhook de Kyverno. Sin esos ajustes, es común ver estados “out-of-sync” ruidosos o fallas de apply en recursos grandes (como CRDs).
Desde el lado de Kyverno, el enfoque se apoya en políticas tipo Validate para baseline de seguridad y en la biblioteca oficial de policies como punto de partida. El beneficio técnico es claro: no hay que inventar controles desde cero en cada equipo, pero sí se deja espacio para extender con reglas propias en un directorio de plantillas versionado.
La documentación oficial de Kyverno refuerza este modelo: políticas como recursos declarativos, evaluación en admisión, y compatibilidad con ciclo completo (validar, mutar, generar y cleanup). Cruzado con la checklist de seguridad de Kubernetes, este enfoque encaja bien para materializar controles de red, permisos y hardening de pods de forma repetible.
Qué deberían hacer los administradores o equipos técnicos
1) Arrancar con baseline y modo Audit. Definir un conjunto mínimo de políticas de seguridad y ejecutarlas en audit durante una o dos iteraciones de release. El objetivo es medir impacto real antes de bloquear.
2) Separar políticas por criticidad. Mover a Enforce primero lo que evita riesgos altos y baja tasa de falsos positivos (privileged containers no justificados, host namespaces, externalIPs sin control).
3) Integrar políticas al flujo GitOps. Políticas en el mismo ciclo de PR, revisión y promoción por entorno. Sin cambios manuales directos sobre cluster para evitar desviaciones.
4) Definir SLO de cumplimiento. Medir violaciones por namespace, tiempo de remediación y porcentaje de políticas en Enforce. Sin métricas, la gobernanza se vuelve solo “intención”.
5) Plan de rollback explícito. Toda política nueva en Enforce debe tener criterio de reversión rápido para evitar incidentes de disponibilidad por bloqueos imprevistos.
Conclusión
La novedad no es solo “usar Kyverno con Argo CD”, sino tratar seguridad de plataforma como una práctica continua de ingeniería: versionada, auditable y desplegable en fases. Para operaciones, esto significa menos excepciones ad-hoc y más consistencia entre clusters. Para seguridad, implica controles aplicados en el punto correcto del ciclo: antes de que el recurso entre en producción.
En un contexto donde Kubernetes sigue creciendo en complejidad, este patrón ofrece un equilibrio pragmático entre velocidad de entrega y disciplina operativa. No reemplaza diseño de arquitectura ni gestión de riesgo, pero sí reduce la brecha entre política definida y política realmente aplicada.
Fuentes
- CNCF: GitOps policy-as-code con Argo CD y Kyverno
- Kyverno Documentation: Introduction
- Kubernetes Security Checklist