یک حسابرسی فنی (Technical Audit) اخیر، پیکربندی‌های پیش‌فرض امنیتی در ۱۵ مورد از Helm Chartهای رسمی که برای سرویس‌دهی AI، پایگاه‌های داده برداری (Vector Databases) و عوامل Model Context Protocol (MCP) استفاده می‌شوند را مورد بررسی قرار داده است. این تحلیل شامل ابزارهایی نظیر KubeRay، vLLM، LiteLLM، Qdrant، Weaviate و Flux159 MCP می‌شود.
یافته‌های کلیدی از تحلیل مانیفست‌ها و تست‌های Lateral Movement
نتایج حاصل از تحلیل استاتیک و بررسی‌های عملی روی کلاسترهای تست، نقاط ضعف بحرانی زیر را نشان می‌دهد:
- مدیریت نامناسب Secrets: در ابزار LiteLLM، فرآیند Migration دیتابیس باعث می‌شود رمزهای عبور خام (Plaintext) مستقیماً در متغیرهای محیطی (Environment Variables) کانتینر قرار گیرند.
- اجرای کد از راه دور بدون احراز هویت (Unauthenticated RCE): تنظیمات پیش‌فرض KubeRay اجازه ارسال Jobهای جدید را از طریق HTTP بدون نیاز به احراز هویت می‌دهد که منجر به اجرای دستورات در کانتینری با دسترسی passwordless sudo می‌شود.
- دسترسی‌های بیش از حد Agents: سرور Kubernetes MCP در Flux159 یک ClusterRole را Mount می‌کند که دسترسی خواندن Secretها در سطح کلاستر و مجوز pod exec را دارد و این دسترسی‌ها بدون Token احراز هویت از طریق HTTP در دسترس هستند.
چالش‌های ابزارهای اسکن استاتیک
یکی از یافته‌های مهم این تحقیق، ناتوانی ابزارهای رایج تحلیل استاتیک مانند Checkov، Trivy و Kubescape در بازرسی Podهایی است که درون Custom Resource Definitions (CRDs) مانند کلاسترهای Ray تعریف شده‌اند. این موضوع نشان می‌دهد که بسیاری از آسیب‌پذیری‌های زیرساختی در محیط‌های Cloud Native AI ممکن است توسط اسکنرهای استاندارد شناسایی نشوند.
