El escaneo en CI no cierra el ciclo
La mayoría de equipos ya escanea imágenes en el pipeline. Eso es necesario. No es suficiente.
Entre el build y el runtime hay margen para que una imagen distinta llegue al cluster: un tag reutilizado, un despliegue manual, un entorno que no pasa por el mismo gate, un registry secundario. Si la única barrera vive en CI, el API server de Kubernetes sigue aceptando cualquier Pod que cumpla el manifiesto.
La pregunta útil no es si se escanea. Es en qué momento se puede rechazar una imagen con evidencia de vulnerabilidades y una política explícita.
Qué decide un control de admisión
Un ValidatingAdmissionWebhook interviene cuando el API server evalúa la creación o actualización de un recurso. Si el webhook responde allowed: false, el objeto no entra. No hace falta confiar en que el operador lea un informe después del hecho.
Eso convierte la postura de vulnerabilidades de un informe en una decisión operativa: permitir, advertir o auditar según reglas definidas.
Qué hace KATANA
KATANA es nuestro control plane open-source para esa decisión. Antes de que un Pod aterrice, consulta un backend de escaneo configurado (JFrog Xray y/o Amazon Inspector sobre ECR), aplica políticas (deny, warn, audit), registra detecciones y puede imponer el resultado a través del webhook nativo de Kubernetes.
En la práctica:
- la política vive en SQLite o en CRDs
ImagePolicy - el evaluador deriva severidad y aplica excepciones por namespace cuando corresponde
- el modo dry-run permite observar impacto sin bloquear despliegues
- hay UI por cluster y una vista fleet con métricas Prometheus para varios entornos
El API server sigue siendo quien bloquea. KATANA aporta la evaluación y la evidencia.
Por qué importa el dry-run
Activar enforcement el primer día suele generar rechazo político, no técnico. Equipos de plataforma y producto necesitan ver qué se habría bloqueado, con qué mensaje y sobre qué imagen, antes de endurecer la regla.
El dry-run convierte la conversación de “esto va a romper producción” en una lista concreta de hallazgos y excepciones. Después, deny deja de ser una opinión y pasa a ser una decisión documentada.
Límites que conviene asumir
KATANA no sustituye el escáner. Depende de la calidad y cobertura del backend (Xray, Inspector u otros que se integren). Tampoco resuelve por sí solo supply chain firmada, runtime detection ni posture de red.
Su trabajo es acotar un punto concreto: en el momento de la admisión, ¿esta imagen cumple la política que la organización ha definido?
Cómo lo usamos con clientes
En engagements de DevSecOps y plataformas Kubernetes partimos de esa pregunta. Evaluamos qué se escanea hoy, qué llega al cluster sin pasar por el mismo control, y dónde un admission gate aporta más que otro informe.
KATANA es tooling propio que ponemos al alcance de nuestros clientes cuando el problema es ese: cerrar el hueco entre el escaneo y el runtime.
Repositorio: github.com/zpol/katana. Si quiere revisar admisión de imágenes en su plataforma, puede agendar una reunión o consultar DevSecOps & Automatización.