گوگل کلاود سرویس مدیریتشدهی GKE Agent Sandbox را عرضه کرده است، در حالی که پروژهی متنباز kubernetes-sigs/agent-sandbox همین قابلیت را برای هر کلاستر کوبرنتیز فراهم میکند. هر دو مورد، یک کانتینر لینوکس یکبارمصرف برای عاملهای هوش مصنوعی (AI agents) در اختیار توسعهدهندگان قرار میدهند و سایر بخشهای زیرساخت را بدون تغییر باقی میگذارند.
چرا کدهای تولیدشده توسط هوش مصنوعی به یک محیط ایزوله نیاز دارند
عاملهای هوش مصنوعی مدرن فقط به سوالات پاسخ نمیدهند. آنها اسکریپت مینویسند، در وب جستجو میکنند، دستورات شل (shell commands) اجرا میکنند و حتی سرویسهای وب را راهاندازی میکنند. این قدرت یک شکاف امنیتی ایجاد میکند: کدی که آنها تولید میکنند میتواند دارای باگ، مخرب یا بیش از حد تهاجمی باشد. عاملی که دستور rm -rf / را اجرا کند یا بدون اجازه به یک پایگاه داده داخلی متصل شود، میتواند کل سیستم را به خطر بیندازد.
یک سندباکس (sandbox)، هر عامل را در کانتینر مخصوص به خود ایزوله میکند؛ یعنی یک ماشین مجازی کوچک و یکبارمصرف. اگر عامل رفتار نادرستی از خود نشان دهد، آسیب در همان کانتینر باقی میماند و میزبان (host) و سایر بارهای کاری (workloads) ایمن میمانند. سرویس جدید GKE و پروژهی مبتنی بر جامعه (community-driven)، این ایده را به یک سرویس آمادهی استفاده تبدیل کردهاند.
دو روش برای داشتن یک سندباکس
- GKE Agent Sandbox – یک سرویس کاملاً مدیریتشده برای مشتریان Google Cloud.
kubernetes-sigs/agent-sandbox– یک پروژهی متنباز برای هر کلاستر کوبرنتیز.
هر دو از معماری هستهای یکسانی بهره میبرند که بر پایهی اصول اولیه (primitives) استاندارد کوبرنتیز بنا شده است.
ساختار سیستم چگونه است
| بخش (Component) | نقش (Role) |
|---|---|
| Sandbox | کانتینر ایزولهای که کد عامل را اجرا میکند. این کانتینر دارای نام ثابت و در صورت نیاز، ذخیرهسازی پایدار (persistent storage) است. |
| SandboxTemplate | یک طرح اولیه (blueprint) که ایمیج کانتینر و سیاستهای امنیتی را تعریف میکند؛ در واقع دستورالعملی برای ساخت سندباکسهای جدید. |
| SandboxClaim | درخواستی که توسط یک عامل (یا کنترلر آن) برای راهاندازی یک سندباکس از یک قالب مشخص صادر میشود. |
| SandboxWarmPool | مجموعهای از سندباکسهای از پیش ساخته شده که آمادهی تحویل فوری هستند. نگه داشتن کانتینرها در حالت آماده (warm)، از تأخیر ناشی از کشیدن ایمیج (pulling images) و راهاندازی یک پاد (pod) جدید در هر بار جلوگیری میکند. |
وقتی یک عامل به محیط نیاز دارد، یک SandboxClaim ارسال میکند. کنترلر، استخر گرم (warm pool) را بررسی کرده، یک سندباکس بیکار را انتخاب میکند و آن را به درخواست متصل مینماید. اگر استخر خالی باشد، یک سندباکس تازه از روی قالب میسازد؛ در غیر این صورت، فرآیند تحویل در عرض چند میلیثانیه انجام میشود.
تنظیمات امنیتی قابل تغییر
- Default-deny networking (شبکهی پیشفرضِ ممنوع) – به طور پیشفرض، یک سندباکس نمیتواند به شبکهی داخلی دسترسی داشته باشد. شما باید قوانین صریحی برای اجازه دادن به اتصالات ورودی یا خروجی اضافه کنید تا از قرارگیری ناخواسته سرویسهای داخلی در معرض خطر جلوگیری شود.
- Isolation levels (سطوح ایزولاسیون) – زماناجرای کانتینر (container runtime) را متناسب با میزان تحمل ریسک خود انتخاب کنید:
- کانتینرهای استاندارد برای سرعت بیشتر،
- gVisor برای داشتن یک لایهی ایزولاسیون اضافی در فضای کاربر (user-space)، یا
- Kata Containers برای ایزولاسیون مبتنی بر سختافزار که مانند یک ماشین مجازی سبک عمل میکند.
- SDKs – کتابخانههای کلاینت Python و Go به توسعهدهندگان اجازه میدهند تا سندباکسها را به صورت برنامهنویسیشده ایجاد، درخواست و حذف کنند که با جریان کاری خط لولههای (pipelines) مبتنی بر هوش مصنوعی مطابقت دارد.
چه کسانی سود میبرند و چه کسانی ممکن است مخالفت کنند
خلاصه کلام
اختصاص دادن یک محیط لینوکس یکبارمصرف به عاملهای هوش مصنوعی، بزرگترین عامل ناشناخته در اتوماسیون مبتنی بر هوش مصنوعی را از میان میبرد: ریسک خراب شدن میزبان توسط کدهای تولیدشده. سرویس مدیریتشدهی GKE Agent Sandbox گوگل کلاود و پروژهی kubernetes-sigs/agent-sandbox که توسط جامعه مدیریت میشود، این ایزولاسیون را هم برای محیطهای ابری (cloud-native) و هم برای محیطهای محلی (on-prem) کاربردی میکنند. سازمانهایی که نیاز دارند بین چابکی و امنیت تعادل برقرار کنند، اکنون ابزاری ملموس و بومیِ کوبرنتیز در اختیار دارند تا کدهای تولیدشده توسط هوش مصنوعی را در یک محیط ایزولهی امن نگه دارند.