O escaneo en CI non pecha o bucle
A maioría dos equipos xa escanea imaxes no pipeline. É necesario. Non é suficiente.
Entre o build e o runtime hai marxen para que unha imaxe diferente chegue ao cluster: un tag reutilizado, un deploy manual, un entorno que salta o mesmo gate, un rexistro secundario. Se a única barreira vive en CI, o API server de Kubernetes aínda acepta calquera Pod que coincida co manifesto.
A pregunta útil non é se escanean. É cando poden rexeitar unha imaxe con evidencia de vulnerabilidades e unha política explícita.
Que decide realmente o admission control
Un ValidatingAdmissionWebhook execútase cando o API server avalía create ou update. Se o webhook devolve allowed: false, o obxecto non entra. Non fai falta que os operadores lean un informe a posteriori.
Iso converte a postura de vulnerabilidades dun informe nunha decisión operativa: permitir, advertir ou auditar baixo regras definidas.
Que fai KATANA
KATANA é o noso control plane open-source para esa decisión. Antes de que un Pod aterrice, consulta un backend de escaneo configurado (JFrog Xray e/ou Amazon Inspector en ECR), aplica políticas (deny, warn, audit), rexistra deteccións e pode facer cumprir o resultado mediante o webhook nativo de Kubernetes.
Na práctica:
- a política vive en SQLite ou en CRDs
ImagePolicy - o avaliador deriva severidade e aplica excepcións de namespace cando está configurado
- o modo dry-run mostra o impacto sen bloquear deploys
- hai unha UI por cluster e unha vista de frota con métricas Prometheus entre entornos
O API server segue sendo o compoñente que bloquea. KATANA achega avaliación e evidencia.
Por que importa o dry-run
Activar o enforcement o primeiro día adoita crear fricción política, non dúbida técnica. Plataforma e produto necesitan ver que se tería bloqueado, con que mensaxe e sobre que imaxe, antes de endurecer unha regra.
O dry-run converte «isto romperá produción» nunha lista concreta de achados e excepcións. Despois, deny é unha decisión documentada, non unha opinión.
Límites que conviene dicir
KATANA non substitúe o escáner. Depende da calidade e cobertura do backend (Xray, Inspector ou outras integracións). Tampouco resolve, por si só, a cadea de subministración asinada, a detección en runtime nin a postura de rede.
O seu traballo é estreito: no momento de admisión, esta imaxe cumpre a política que a organización definiu?
Como o usamos con clientes
En traballo de DevSecOps e plataforma Kubernetes partimos desa pregunta. Avaliamos que se escanea hoxe, que chega ao cluster sen o mesmo control, e onde un gate de admisión engade máis que outro informe.
KATANA é o noso tooling propio. Poñémolo á disposición dos clientes cando o problema é pechar o gap entre escaneo e runtime.
Repositorio: github.com/zpol/katana. Para revisar a admisión de imaxes na súa plataforma, agende unha reunión ou consulte DevSecOps & Automation.