‏k8s-aibom؛ فهرست خودکار قطعات هوش مصنوعی روی کوبرنتیز

نقطهٔ شروع این مطلب یه سؤال آشنا برای تیم‌های امنیته: با shadow AI چه‌کار باید کرد؟ به گفتهٔ نویسنده، workloadهایی که توسعه‌دهنده‌ها بدون ثبت رسمی دیپلوی می‌کنن معمولاً از دید اسکنرهای سنتی فرار می‌کنن، چون سازمان‌ها حاضر نیستن با اجبار به DaemonSetهای privileged، دسترسی سطح کرنل و ویرایش دستی pod-spec، سرعت توسعه و پایداری رو فدا کنن.

پاسخ گوگل به این بن‌بست، متن‌باز کردن k8s-aibom‌ه: یه کنترلر کوبرنتیز سبک و بدون دسترسی privileged که مدام API کلاستر و محیط کانتینرها رو رصد می‌کنه تا رانتایم‌های در حال اجرای هوش مصنوعی (مثل vLLM و Triton) رو خودکار تشخیص بده و برایشون سند استاندارد CycloneDX ML-BOM (فهرست قطعات یادگیری ماشین) تولید کنه.

معماری‌اش عمداً بدون اصطکاکه: یه Deployment تنها و unprivileged تو namespace‌ای به اسم k8s-aibom-system — بدون سایدکار، بدون ماژول کرنلی eBPF، بدون DaemonSet با دسترسی ویژه و بدون هیچ تغییری تو pod specهای موجود. تیم‌های اپلیکیشن حتی لازم نیست پایپ‌لاین CI/CD‌شون رو دست بزنن.

خط لولهٔ کشف چهار مرحله داره: اول منابع کلاستر (KServe، Deployment، StatefulSet، DaemonSet و Job) اسکرپ می‌شن؛ بعد با pattern matching روی ایمیج کانتینر، متغیرهای محیطی و آرگومان‌های خط فرمان، استک‌های هوش مصنوعی شناسایی می‌شن — از رانتایم‌های سرو مثل vLLM و Triton و TGI و Ollama تا فریم‌ورک‌های ایجنت مثل LangChain و AutoGen و CrewAI و دیتابیس‌های وکتور مثل Milvus و Qdrant و pgvector؛ بعد سند CycloneDX 1.6 ساخته می‌شه؛ و در آخر به وضعیت یه Custom Resource (فیلد status.bomDocument) می‌چسبه و اختیاراً به باکت Cloud Storage یا وب‌هوک بیرونی هم می‌ره.

یه ویژگی مهم اینه که ابزار وضعیت کلاستر رو مثل ورودی یه تابع خالص می‌بینه: ورودی یکسان، خروجی ML-BOM بایت‌به‌بایت یکسان. همین determinism باعث می‌شه با جریان‌های GitOps جور دربیاد و SREها بتونن diff دقیق بگیرن و موقع drift وابستگی‌های هوش مصنوعی هشدار دقیق بسازن.

نویسنده تفاوتش با ابزارهای موجود رو هم توضیح می‌ده: بیشتر راهکارهای AIBOM اسکنر زمان build هستن و BOM رو از artifactهای ساکن می‌سازن، یعنی کدی که قرار بود دیپلوی بشه. پلتفرم‌های تجاری هم معمولاً با اسکن بیرونی و مدل دادهٔ اختصاصی کار می‌کنن. ادعای k8s-aibom اینه که BOM رو از مشاهدهٔ زندهٔ کلاستر می‌سازه، خروجی‌اش با اکوسیستم OWASP و OpenSSF سازگاره و مکمل ابزارهای موجوده نه جایگزینشون.

برای حسابرس‌ها هم یه Confidence Model سه‌سطحی تعریف شده: Declared یعنی چیزی که صراحتاً تو پیکربندی اعلام شده (مثلاً آرگومان --model meta-llama/Llama-2-7b) و نشون‌دهندهٔ نیت روشن انسانه؛ Inferred یعنی چیزی که موتور pattern matching خودش استنتاج کرده (مثل تطبیق امضای ایمیج vLLM)؛ و Unresolved برای وقتیه که حضور هوش مصنوعی قطعیه ولی مدل و وزن‌ها و نسخه‌ها قابل تعیین نیستن — که بلافاصله workload رو برای بازبینی امنیتی علامت می‌زنه.

لایهٔ اعتماد هم روی least privilege و تغییرناپذیری بنا شده: کنترلر با یه service account اختصاصی و Workload Identity حداقلی کار می‌کنه و فقط roles/storage.objectCreator می‌خواد، و نوشتن روی Cloud Storage با precondition نوع DoesNotExist انجام می‌شه، یعنی هر ML-BOM بعد از نوشته‌شدن عملاً غیرقابل بازنویسیه. گوگل این خروجی رو به چارچوب‌های حاکمیتی هم گره می‌زنه: مادهٔ ۱۲ و مادهٔ ۵۰ قانون هوش مصنوعی اتحادیهٔ اروپا، چارچوب مدیریت ریسک NIST AI RMF و استاندارد ISO/IEC 42001. کد پروژه هم روی گیت‌هاب در دسترسه.

نکات کلیدی:

• k8s-aibom یه کنترلر متن‌باز و بدون دسترسی privileged برای کشف خودکار workloadهای هوش مصنوعی تو کوبرنتیزه
• بدون سایدکار، eBPF، DaemonSet ویژه یا تغییر pod spec و پایپ‌لاین CI/CD کار می‌کنه
• خروجی، سند استاندارد CycloneDX 1.6 ML-BOM‌ه، نه فرمت اختصاصی وندور
• BOM از مشاهدهٔ زندهٔ کلاستر ساخته می‌شه، نه اسکن artifact در زمان build
• خروجی قطعی (deterministic) با ورودی یکسان، مناسب GitOps و تشخیص drift
• مدل اطمینان سه‌سطحی Declared / Inferred / Unresolved نیت انسانی رو از استنتاج ماشین جدا می‌کنه
• نوشتن غیرقابل‌بازنویسی روی Cloud Storage و نگاشت به EU AI Act، NIST AI RMF و ISO/IEC 42001