CI scanning-ek ez du begizta ixten
Talde gehienek irudiak pipeline-an eskaneatzen dituzte jada. Beharrezkoa da. Ez da nahikoa.
Build-aren eta runtime-aren artean irudi desberdin bat clusterrean sartzeko tartea dago: berrerabilitako tag bat, deploy eskuzkoa, ate bera saltatzen duen ingurunea, bigarren erregistro bat. Oztopo bakarra CI-n bizi bada, Kubernetes API server-ak manifioarekin bat datorren edozein Pod onartzen jarraitzen du.
Galdera erabilgarria ez da eskaneatzen duzuen ala ez. Noiz uka dezakezuen irudi bat zaurgarritasun-frogekin eta politika esplizitu batekin.
Zer erabakitzen du benetan admission control-ek
ValidatingAdmissionWebhook bat API server-ak create edo update ebaluatzen duenean exekutatzen da. Webhook-ak allowed: false itzultzen badu, objektua ez da sartzen. Operadoreek ez dute txostenik irakurri behar geroago.
Horrek zaurgarritasun-postura txosten batetik erabaki operatibo bihurtzen du: baimendu, abisatu edo auditatu, definitutako arauen arabera.
Zer egiten du KATANA-k
KATANA erabaki horretarako gure open-source control plane da. Pod bat atera aurretik, konfiguratutako scan backend bat kontsultatzen du (JFrog Xray eta/edo Amazon Inspector ECR-n), politikak aplikatzen ditu (deny, warn, audit), detekzioak erregistratzen ditu eta emaitza Kubernetes webhook natiboaren bidez betearazi dezake.
Praktikan:
- politika SQLite-n edo
ImagePolicyCRDetan bizi da - ebaluatzaileak larritasuna deribatzen du eta namespace salbuespenak aplikatzen ditu konfiguratuta dagoenean
- dry-run moduak inpaktua erakusten du deploy-ak blokeatu gabe
- cluster bakoitzeko UI eta fleet ikuspegi bat daude Prometheus metrikoekin
API server-a blokeatzen duen osagaia izaten jarraitzen du. KATANA-k ebaluazioa eta froga ematen ditu.
Zergatik garrantzitsua den dry-run
Enforcement lehen egunean aktibatzeak marruskadura politikoa sortzen du normalean, ez zalantza teknikoa. Plataforma- eta produktu-taldeek ikusi behar dute zer blokeatuko zen, zein mezuarekin eta zein iruditan, araua gogortu aurretik.
Dry-run-ek «horrek ekoizpena apurtuko du» aurkikuntza eta salbuespenen zerrenda zehatz bihurtzen du. Ondoren, deny dokumentatutako erabakia da, iritzi bat ez.
Adierazi beharreko mugak
KATANA-k ez du eskanerra ordezkatzen. Backend-aren kalitatearen eta estalduraren menpe dago (Xray, Inspector edo beste integrazioak). Berez, ez du sinatutako supply chain, runtime detekzioa edo sare-postura konpontzen.
Bere lana estua da: admission unean, irudi honek erakundeak definitutako politika betetzen du?
Nola erabiltzen dugu bezeroekin
DevSecOps eta Kubernetes plataforma-lanean galdera horretatik hasten gara. Gaur zer eskaneatzen den, kontrol berarekin clusterrean zer iristen den, eta non admission gate batek beste txosten bat baino gehiago gehitzen duen ebaluatzen dugu.
KATANA gure tooling propioa da. Bezeroei eskaintzen diegu arazoa scanning-aren eta runtime-aren arteko tartea ixtea denean.
Biltegia: github.com/zpol/katana. Zure plataformako irudien admission berrikusteko, bilera agendatu edo ikusi DevSecOps & Automation.