Az AI ellátási lánc biztonságossá tétel a GKE-n: Bevezetés a k8s-aibom-ba, amely automatizált AI-komponensek listákat biztosít.

A biztonsági csapatod hogyan tudja kezelni a “shadow AI”-t? A fejlesztők által telepített, hivatalos regisztráció nélkül helyezett fel terhelések gyakran elkerülik a hagyományos biztonsági szkennerek, mivel az szervezetek nem hajlandóak lassítani a fejlesztést és aláásni a stabilitást, ha követelnek jogosult DaemonSets-eket, kernel-szintű hozzáférést, és manuális pod-spec módosításokat. Azt hogy ezt a megállást, ma nyitott forráskódúvá tesszük a k8s-aibomot. Ez a könnyű, jogosultság nélküli Kubernetes vezérlő folyamatosan figyeli a kluster API-t és a konténer környezeteket, hogy automatikusan felismerje a futó AI futtatókat (pl. vLLM és Triton), és létrehozzon standard CycloneDX Machine Learning Bill of Materials (ML-BOM) dokumentumokat. Az automatizált, ellenőrzhető betekintést, amely közvetlenül a futó időből érhető el – függetlenül attól, hogy a terhelés hivatalosan regisztrálva van vagy nem –, a k8s-aibom segíthet a csapatoknak biztonságosan átvinni az AI projekteket a tesztelésből a termelési környezetbe, anélkül, hogy a fejlesztők integrációjában akadályoznák őket. A k8s-aibom “zero friction” architektúrája a CISO teljes áttekintési követelménye és az SRE kluster-stabilitási követelménye alapján lett megtervezve. Egyetlen, jogosultság nélküli Deploymentként telepíti a k8s-aibom-rendszer névtérben. A “zero friction” elv: nincs sidecar, nincs eBPF kernel modul, nincs jogosult DaemonSets, és nincs módosítás a meglévő fejlesztői pod specifikációkon. A k8s-aibom az AI terheléseket és BOM-okat hozza létre. A felfedezési folyamat négy világos szakaszban fut: Kluster terhelések begyűjtése: A vezérlő folyamatosan figyeli a KServe erőforrásokat, Deployment-eket, StatefulSets-eket, DaemonSets-eket és Job-okat a klusterben. AI stackok azonosítása: A fejlett mintamásolás elemzi a konténer kép-t, környezeti változókat és parancssor argumentumokat, hogy azonosítsa a futó környezeteket (vLLM, Triton Inference Server, TGI, Ollama), autonóm agent kereteket (LangChain, AutoGen, CrewAI), vektor adatbázisokat és RAG tárolókat (Milvus, Qdrant, pgvector), valamint a terjesztett edületi munkákat és értékelési eszközöket. Standard manifestumok létrehozása: A vezérlő azonosított elemeket formális OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM) dokumentumokban gyűjti össze. Küldés: A vezérlő a létrehozott ML-BOM-ot közvetlenül a klusterben található AIBOM Custom Resource (CR) saját erőforrásának (status.bomDocument) állapotába (status) helyezi, és küldi ki opcionális külső csatornákra, beleértve a Google Cloud Storage tárolókat és külső webhook végpontokat. Az alkalmazási csapatok nem kell módosítani a pod specifikációikat, beépíteni sidecar-okat, vagy módosítani a CI/CD pipeline-jeiket. A k8s-aibom a Kubernetes kluster állapotát egy funkcionális bemenőként kezeli: Azaz azonos kluster bemenetek byte-szintű ML-BOM dokumentumokat hoznak létre. Ez a determinisztikus tulajdonság teszi a k8s-aibomot ideálisnak a GitOps munkaterületekhez, lehetővé téve a Site-Reliability Engineers (SRE) számára, hogy pontos különbségeket végezzenek el, és észleljenek pontos változási figyelmeztetéseket, amikor az AI-függőségek eltérnek. Hol a meglévő AIBOM eszközök hihetetlen: Sok AI BOM megoldás csak a “build-time” szkeneerekkel hoz létre BOM-okat a piacon lévő elemekből. Ezek segítenek nyomon követni a kódot, amelynek a telepítésre szánt, de a kereskedelmi AI biztonsági platformok kiterjesztik ezt a képet, elsősorban külső szkenelemekkel, amelyek a vendor-specifikus adatmodelleken alapulnak. Kevesebb, ha egyáltalában, ezek a eszközök segítik a compliance-felügyelőket, a SecOps csapatokat és a platformmérnerei, hogy megértsék, mi fut jelenleg, miről van szó, és hogyan lehet ezt ellenőrizni. A k8s-aibomot mi terveztük, hogy ezt a hiányt fedjük. Ez a BOM-okat az élő kluster megfigyeléséből, a szkenelemek szkeneletről hozza létre, standard-konform CycloneDX 1.6 ML-BOM-okat hoz létre, amelyek azonosulnak a szélesebb OWASP és Open Source Security Foundation (OpenSSF) ellátási lánc ökoszisztémájával, nem pedig vendor-specifikus formátumokkal, és jogosultság nélküli vezérlőként fut egy megfelelőségi Kubernetes klusterben, így kiegészítő eszkökként működik, nem pedig helyettesítőként. A Bizalom Modellt: Elválasztva az Intentet az Inferencia: A compliance-felügyelőkre és a SecOps mérnökeire a “raw” telemetry sokszor zaj, a szabványos monitorozó eszközök azt mutatják, hogy egy konténer fut, de nem bizonyítják, hogy egy AI modell expliciten egy platformmérnök konfigurálta-e, vagy egy autonóm szkript futtatta a futó időben. A k8s-aibom ezt a kettősséget a determinisztikus Bizalom Modelljével oldja meg, amely a felfedett erőforrásokat különböző szintekbe kategorizálja: “Megjelölt”: Expliciten meg van definiálva a felhasználó vagy a fejlesztő a terhelés konfigurációjában (Például a `–model meta-llama/Llama-2-7b argumentumok). A “megjelölt” bizalom detektálás egyértelmű emberi intet jelzi. “Inferencia”: A vezérlő pattern-matching motorja a konténer kép-t, környezeti változókat és végrehajtási profilt használva automatikusan vonja le. (Például a ^vllm/.* konténer-t azonosítja). “Megbízhatatlan”: Ez a terhelésekre van alkalmazva, ahol egy aktív AI jelenlétet észlelnek, de a pontos modellparamétereket, súlyokat és verziókat nem lehet determinisztikusan meghatározni. A “megbízhatatlan” detektálás azonnal jelzi a terhelést, hogy célzott biztonsági értékelést végezzenek el. Ez a struktúrált taxonómia lehetővé teszi a compliance-felügyelőkre, hogy azonnal megkülönböztessék az explicit mérnöki intet a gépi vonalaktól, és egy alátámasztott hitet biztosítsanak a vizsgálatok során. Az immutabilitást és a minimális jogosultságot: Az audit-szintű biztonsági modell építése: A compliance-felügyelőkre a szabványos megfigyelési adatok a logok és a metrikák, amelyek megváltozhatnak, eldobhatók, vagy a felhasználhatók. A k8s-aibom egy audit-szintű bizonyíték-utat épít, amely szigorú minimális jogosultság és adati immutabilitás alapján épül. A vezérlő egy dedikált Kubernetes szolgáltatás fiókhoz tartozik, amely egy minimális Identity and Access Management (IAM) Workload Identity-hez tartozik. Csupán a szerep/tárolás.objectCreator engedélyek szükségesek. A legszigorúbb audit és bizonyítékkontig a Google Cloud Storage külső csatornának “DoesNotExist” előfeltétjeit kell alkalmazni. Amikor egy ML-BOM-ot írnak a Google Cloud Storage tárolóba, akkor az objektum kriptográfiailag megváltoztatható. Nem lehet csendben átírni, módosítani, vagy retroaktiv módon átjátszani a kluster-aktívok vagy a rossz terhelések által. A SecOps csapatok teljes biztoságot kapnak, hogy a visszaigazított audit log, amelyet a szabályozóknek mutatnak, az egyváltozatú rekord a kluster-végrehajtásról. Azok a feladatok, amelyek a szabályozók által követelnek, könnyebben megvalósíthatók. A teljesítmény-fokozás: A globális szabványokhoz való betartás A k8s-aibom automatizált CycloneDX 1.6 ML-BOM-ok generálása által közvetlenül lezárja a gapot a alacsony szintű Kubernetes-végrehajtási állapot és a magas szintű irányítói-kódok között. Azok a GKE AI-deploy-ok, amelyek késnek, akkor ezt az alapvető empirikus adatot tudják használni, amely elengedhetetlen a nemzetközi szabványokhoz: EU AI Act: Segít a szervezeteknek az 12. cikk (folyamatos nyomon követés és rekordok) és az 50. cikk (az AI rendszerek átláthatósági követelményei) betartásában, és az AI-t tartalmazó technikai bizonyítékok összegyűjtésében, amelyek szükségessé válnak a megfelelési ellenőrzések során. NIST AI Risk Management Framework (AI RMF): Folyamatos, empirikus eszköz-láthatóságot biztosít, amely segít a Govern, Map, Measure, and Manage funkciókban, és a megfelelési folyamatokat a manuális ellenőrzésekből automatizált eszköz-nyomon követési átállásba. ISO/IEC 42001: Segít a compliance-efforts-okban az AI-menedzsment rendszerek eszköz-lehetőségi feltárásában és az nyomon követésében, csökkentve a manuális táblázatok vagy a periódusos snapshot-ellenőrzésekre való támaszkodást. A k8s-aibom használatba vétel: Azok a csapatok, akik a CIS-t, a jogi, a compliance és a biztonsági csapatok, a SecOps csapatok, a platformmérnerei és a fejlesztők, akik a k8s-aibom-ot használják, hogy a sokoldalú problémát megoldják. A k8s-aibom-ot megvizsgálhatod, a CRD-k-t, és hozzájárulhatsz a nyílt forráskódú k8s-aibom projekthez.