L’escaneig a CI no tanca el bucle
La majoria d’equips ja escaneja imatges al pipeline. Cal. No és suficient.
Entre el build i el runtime hi ha marge perquè una imatge diferent arribi al cluster: un tag reutilitzat, un deploy manual, un entorn que salta el mateix gate, un registre secundari. Si l’única barrera viu a CI, l’API server de Kubernetes encara accepta qualsevol Pod que coincideixi amb el manifest.
La pregunta útil no és si escanegeu. És quan podeu rebutjar una imatge amb evidència de vulnerabilitats i una política explícita.
Què decideix realment l’admission control
Un ValidatingAdmissionWebhook s’executa quan l’API server avalua create o update. Si el webhook retorna allowed: false, l’objecte no entra. No cal que els operadors llegeixin un informe a posteriori.
Això converteix la postura de vulnerabilitats d’un informe en una decisió operativa: permetre, advertir o auditar sota regles definides.
Què fa KATANA
KATANA és el nostre control plane open-source per a aquesta decisió. Abans que un Pod aterrï, consulta un backend d’escaneig configurat (JFrog Xray i/o Amazon Inspector a ECR), aplica polítiques (deny, warn, audit), registra deteccions i pot fer complir el resultat mitjançant el webhook natiu de Kubernetes.
A la pràctica:
- la política viu a SQLite o en CRDs
ImagePolicy - l’avaluador deriva severitat i aplica excepcions de namespace quan està configurat
- el mode dry-run mostra l’impacte sense bloquejar deploys
- hi ha una UI per cluster i una vista de flota amb mètriques Prometheus entre entorns
L’API server continua sent el component que bloqueja. KATANA aporta avaluació i evidència.
Per què importa el dry-run
Activar l’enforcement el primer dia sol crear fricció política, no dubte tècnic. Plataforma i producte necessiten veure què s’hauria bloquejat, amb quin missatge i sobre quina imatge, abans d’endurir una regla.
El dry-run converteix «això trencarà producció» en una llista concreta de troballes i excepcions. Després, deny és una decisió documentada, no una opinió.
Límits que cal dir
KATANA no substitueix l’escàner. Depèn de la qualitat i cobertura del backend (Xray, Inspector o altres integracions). Tampoc resol, per si sol, la cadena de subministrament signada, la detecció en runtime ni la postura de xarxa.
La seva feina és estreta: en el moment d’admissió, aquesta imatge compleix la política que l’organització ha definit?
Com l’usem amb clients
En treball de DevSecOps i plataforma Kubernetes partim d’aquesta pregunta. Avaluem què s’escaneja avui, què arriba al cluster sense el mateix control, i on un gate d’admissió afegeix més que un altre informe.
KATANA és el nostre tooling propi. El posem a disposició dels clients quan el problema és tancar el gap entre escaneig i runtime.
Repositori: github.com/zpol/katana. Per revisar l’admissió d’imatges a la vostra plataforma, agendeu una reunió o consulteu DevSecOps & Automation.