Google Cloud در یک معرفی رسمی تازه، پروژه متنباز k8s-aibom را برای محیطهای Kubernetes و بهویژه GKE معرفی کرده است؛ ابزاری که تلاش میکند یکی از دردسرهای مهم امنیت AI سازمانی را حل کند: اینکه تیم امنیتی دقیقاً بداند چه runtimeها، agent frameworkها، vector databaseها و اجزای AI واقعاً در کلاستر در حال اجرا هستند، نه فقط چه چیزی روی کاغذ یا در registry ثبت شده است.
مسئله از جایی شروع میشود که تیمهای توسعه برای سرعتدادن به آزمایش و استقرار، workloadهای AI را بدون ثبت رسمی یا بدون هماهنگی کامل با تیم امنیتی بالا میآورند. در چنین حالتی، ابزارهای سنتی inventory یا اسکن image همیشه تصویر دقیقی از runtime واقعی نمیدهند. گوگل دقیقاً روی همین فاصله تمرکز کرده و میگوید k8s-aibom میتواند از دل execution واقعی کلاستر، Machine Learning Bill of Materials یا همان ML-BOM را استخراج کند.
k8s-aibom چه کاری انجام میدهد؟
طبق توضیح رسمی Google Cloud، این ابزار یک کنترلر Kubernetes سبک و بدون نیاز به دسترسی privileged است که API کلاستر و محیط containerها را پایش میکند. هدف آن، تشخیص runtimeهایی مثل vLLM، Triton Inference Server، TGI و Ollama، همچنین frameworkهایی مثل LangChain، AutoGen و CrewAI و حتی اجزایی مثل Milvus، Qdrant و pgvector است. خروجی این فرایند بهصورت سندهای استاندارد OWASP CycloneDX 1.6 ML-BOM تولید میشود.
این نکته مهم است، چون بحث فقط inventory ساده نیست. وقتی BOM در یک قالب استاندارد منتشر میشود، میتواند وارد فرایندهای governance، ممیزی، risk review و حتی policy engineهای موجود سازمان شود. به بیان دیگر، k8s-aibom تلاش میکند AI visibility را از یک موضوع دستی و مبهم، به بخشی از خط کنترل رسمی زیرساخت تبدیل کند.
چرا رویکرد بدون اصطکاک مهم است؟
گوگل روی این نکته تأکید کرده که k8s-aibom بدون sidecar، بدون eBPF kernel module، بدون DaemonSet دارای دسترسی بالا و بدون ویرایش pod spec توسعهدهنده کار میکند. این طراحی از منظر عملیاتی خیلی مهم است. بسیاری از ابزارهای امنیتی دقیقاً زمانی با مقاومت تیم SRE یا پلتفرم روبهرو میشوند که برای visibility بیشتر، پایداری کلاستر را قربانی میکنند یا مسیر توسعه را کند میسازند. اگر یک ابزار امنیتی بخواهد برای هر workload تغییر دستی تحمیل کند، احتمال دورزدن یا نادیدهگرفتن آن بالا میرود.
k8s-aibom تلاش میکند این تضاد کلاسیک میان CISO و SRE را کم کند: امنیت میخواهد دید کامل داشته باشد و عملیات میخواهد ثبات کلاستر حفظ شود. اگر ابزار بتواند با یک deployment غیرممتاز در namespace خودش کار کند و فقط از دادههای قابل مشاهده runtime BOM بسازد، احتمال پذیرش آن در محیطهای production بیشتر میشود.
این خبر برای امنیت AI چه معنایی دارد؟
در عمل، یکی از ریسکهای بزرگ AI سازمانی این است که تیمها مدل، agent یا پایگاه برداری جدیدی را وارد محیط کنند، اما ثبت آن در inventory، policy و فرایند کنترل تغییر عقب بماند. نتیجه میتواند shadow AI، استفاده از dependency نامعلوم یا حتی ناتوانی در پاسخ سریع هنگام incident باشد. k8s-aibom بهتنهایی این مسائل را حل نمیکند، اما زیرساخت دادهای لازم برای حل آنها را میسازد: اول بدانید چه چیزی واقعاً اجرا میشود، بعد درباره مجازبودن، سطح ریسک و مسیر اصلاح تصمیم بگیرید.
این رویکرد از نظر دفاعی با روندهای دیگری که در بازار میبینیم همراستاست. برای مثال، در خبر استفاده اچپیای از شبکه بهعنوان حسگر بلادرنگ تهدیدهای AI هم بحث اصلی visibility و کنترل رفتار در محیط زنده بود. از آن طرف، راهکارهایی مانند Dell PowerProtect One هم نشان میدهند بازار زیرساخت دیگر امنیت را از observability و recovery جدا نمیبیند.
محدودیتها و سؤالهای باز
با این حال باید اغراق نکرد. BOM داشتن با secure بودن یکسان نیست. اگر سازمان بعد از تولید BOM هیچ policy یا واکنشی تعریف نکند، خروجی فقط به یک سند اضافی تبدیل میشود. همچنین pattern matching برای تشخیص runtimeها هرقدر هم خوب باشد، باز ممکن است implementationهای سفارشی یا نامگذاریهای غیرمعمول را از قلم بیندازد. بنابراین k8s-aibom باید بخشی از یک زنجیره بزرگتر باشد: inventory، policy، کنترل دسترسی، logging و مسیر remediation.
همچنین باید دید تیمها این خروجی را به کجا میفرستند. گوگل گفته BOM میتواند در status یک custom resource قرار بگیرد یا به external sinkهایی مثل Google Cloud Storage bucket و webhook ارسال شود. این انعطاف خوب است، اما مسئولیت طراحی گردشکار امن را بر عهده خود سازمان میگذارد. اگر sinkها درست محافظت نشوند یا retention تعریف نشود، همین BOMها ممکن است خودشان به منبع اطلاعات حساس تبدیل شوند.
جمعبندی تحلیلی
معرفی k8s-aibom بیشتر از آنکه یک «ویژگی تزئینی» برای GKE باشد، نشانه بلوغ بحث امنیت زنجیره تأمین AI است. گوگل عملاً پذیرفته که کنترل AI در production فقط با ثبت دستی یا اسکن image حل نمیشود و باید runtime واقعی دیده شود. ارزش اصلی این پروژه در همین people-first بودن آن است: بهجای تحمیل friction شدید به تیمهای توسعه، سعی میکند data لازم برای governance را از خود کلاستر جمع کند. اگر سازمانها آن را با policy و response مناسب ترکیب کنند، k8s-aibom میتواند یکی از قطعات مهم stack دفاعی AI-native در Kubernetes باشد.