Lo scanning in CI non chiude il ciclo
La maggior parte dei team già scansiona le immagini nella pipeline. È necessario. Non è sufficiente.
Tra build e runtime c’è spazio perché un’immagine diversa raggiunga il cluster: un tag riusato, un deploy manuale, un ambiente che salta lo stesso gate, un registry secondario. Se l’unica barriera vive in CI, l’API server di Kubernetes accetta ancora qualsiasi Pod conforme al manifesto.
La domanda utile non è se fate scanning. È quando potete rifiutare un’immagine con evidenza di vulnerabilità e una policy esplicita.
Cosa decide davvero l’admission control
Un ValidatingAdmissionWebhook viene eseguito quando l’API server valuta create o update. Se il webhook restituisce allowed: false, l’oggetto non entra. Gli operatori non devono leggere un report a posteriori.
Questo trasforma la postura sulle vulnerabilità da report in decisione operativa: consentire, avvisare o auditare secondo regole definite.
Cosa fa KATANA
KATANA è il nostro control plane open-source per quella decisione. Prima che un Pod atterri, interroga un backend di scan configurato (JFrog Xray e/o Amazon Inspector su ECR), applica policy (deny, warn, audit), registra le detection e può far rispettare l’esito tramite il webhook nativo di Kubernetes.
In pratica:
- la policy vive in SQLite o in CRD
ImagePolicy - il valutatore deriva la severity e applica eccezioni di namespace quando configurato
- la modalità dry-run mostra l’impatto senza bloccare i deploy
- c’è una UI per cluster e una vista fleet con metriche Prometheus tra ambienti
L’API server resta il componente che blocca. KATANA fornisce valutazione ed evidenza.
Perché conta il dry-run
Attivare l’enforcement il primo giorno di solito crea attrito politico, non dubbio tecnico. Piattaforma e prodotto devono vedere cosa sarebbe stato bloccato, con quale messaggio e su quale immagine, prima di irrigidire una regola.
Il dry-run trasforma «questo romperà la produzione» in un elenco concreto di finding ed eccezioni. Dopo, deny è una decisione documentata, non un’opinione.
Limiti da dichiarare
KATANA non sostituisce lo scanner. Dipende dalla qualità e copertura del backend (Xray, Inspector o altre integrazioni). Non risolve da solo supply chain firmata, detection runtime o postura di rete.
Il suo compito è stretto: al momento dell’admission, questa immagine soddisfa la policy definita dall’organizzazione?
Come lo usiamo con i clienti
Nel lavoro DevSecOps e piattaforma Kubernetes partiamo da quella domanda. Valutiamo cosa viene scansionato oggi, cosa raggiunge il cluster senza lo stesso controllo, e dove un gate di admission aggiunge più di un altro report.
KATANA è il nostro tooling. Lo mettiamo a disposizione dei clienti quando il problema è chiudere il gap tra scanning e runtime.
Repository: github.com/zpol/katana. Per revisionare l’admission delle immagini sulla vostra piattaforma, prenotate una riunione o vedete DevSecOps & Automation.