در این مطلب، بررسی خواهیم کرد که چگونه کانتینرهای سندباکس، ایزوله‌سازی بار کاری را بهبود می‌بخشند، خطرات امنیتی را کاهش می‌دهند و آیا برای زیرساخت مناسب هستند یا خیر.
کانتینرهای سندباکس چیست؟
کانتینرهای سندباکس (Sandboxed Containers) نوعی از container runtime هستند که با ایزوله کردن کانتینرها از سیستم عامل میزبان (OS) و سایر کانتینرها، یک لایه امنیتی اضافی فراهم می‌کنند.
همچنین می‌توانید آن را کانتینرهای مجازی (virtualised containers) نامید.
برخلاف کانتینرهای سنتی (مانند داکر که کرنل سیستم عامل میزبان را به اشتراک می‌گذارد)، کانتینرهای سندباکس از مجازی‌سازی سبک یا سایر مکانیسم‌های ایزوله‌سازی برای ایزوله کردن کامل آنها استفاده می‌کنند.
این امر از حملات نفوذ به کانتینر جلوگیری می‌کند. به این معنی که یک کانتینر نمی‌تواند از محدودیت‌های خود فرار کند و به کرنل سیستم عامل میزبان یا سایر کانتینرها دسترسی پیدا کند.
این امر امنیت قوی‌تری را برای محیط‌های چند مستاجری (multi-tenant) تضمین می‌کند (زمانی که بسیاری از کاربران یا سازمان‌ها از یک سیستم مشترک استفاده می‌کنند.)
برخی از زمان‌های container runtimes سندباکس محبوب عبارتند از:
- gVisor (توسعه یافته توسط گوگل) – یک کرنل user-space که فراخوانی‌های سیستمی را برای تامین امنیت بیشتر رهگیری می‌کند.
- Kata Containers – هر کانتینر را درون یک ماشین مجازی سبک اجرا و از ایزولاسیون قوی کرنل اطمینان حاصل می‌کند.
این ران تایم‌ها به جای اشتراک‌گذاری مستقیم کرنل میزبان، یک لایه اضافی معرفی می‌کنند که دسترسی مستقیم به فراخوانی‌های سیستمی را محدود می‌کند.
این ران تایم‌ها، بارهای کاری را بسیار بهتر از ران تایم‌های کانتینر استاندارد ایزوله می‌کنند.
به عنوان مثال،
- gVisor یک mini-kernel مخصوص به خود (به نام Sentry) را دارد که در فضای کاربر اجرا می‌شود (نه مستقیم روی سیستم عامل میزبان). وقتی یک برنامه درون کانتینر فراخوانی سیستمی انجام می‌دهد، gVisor آن را رهگیری کرده و به جای اینکه اجازه دهد مستقیم به سیستم عامل میزبان برود، آن را شبیه‌سازی (emulates ) می‌کند (وانمود می‌کند که آن را مدیریت می‌کند).
- Kata کانتینرها را در ماشین‌های مجازی سبک اجرا می‌کند. کرنل ماشین مجازی معمولا حدود ۲۰۰ تا ۳۰۰ فراخوانی سیستمی (syscall) را مجاز می‌داند (مشابه یک کرنل لینوکس معمولی). برنامه داخل کانتینر، فراخوانی‌های سیستمی را به کرنل ماشین مجازی انجام می‌دهد، نه به کرنل سیستم عامل میزبان.
ران تایم کانتینر و دسترسی به کرنل میزبان
برای درک کانتینرهای سندباکس شده، ابتدا باید بدانیم که یک کانتینر معمولی چقدر به کرنل میزبان دسترسی دارد.
امروزه اکثر کانتینرها روی ران تایم‌های کانتینر مانند containerd یا cri-o اجرا می‌شوند.
بیایید در نظر بگیریم که هنگام اجرای یک کانتینر ساده چه اتفاقی می‌افتد:
- این کانتینر مستقیم از فراخوانی‌های سیستمی میزبان استفاده می‌کند.
- نسخه و قابلیت‌های کرنل یکسانی را به اشتراک می‌گذارد.
- از طریق قابلیت‌های لینوکس کنترل می‌شود که عملیات دارای امتیاز را محدود می‌کند.
با این حال، با وجود این کنترل‌ها، کانتینرها هنوز هم می‌توانند:
- فراخوانی‌های سیستمی مستقیم (حدود ۳۰۰) به کرنل انجام دهند که در صورت وجود آسیب‌پذیری‌ها می‌تواند مورد سوءاستفاده قرار گیرد.
- اطلاعات نسخه و سیستم کرنل را بخوانند.
- به ماژول‌ها و زیرسیستم‌های کرنل دسترسی داشته باشند (البته با برخی محدودیت‌ها).
این سطح دسترسی هنگام اجرای بارهای کاری غیرقابل اعتماد، به ویژه در محیط‌های چند مستاجری مانند پلتفرم‌های CI/CD، خطر ایجاد می‌کند.
معاملات عملکرد (Performance Trade-offs)
با وجود مزایای امنیتی خوب، کانتینرهای سندباکس با برخی از معاملات عملکرد همراه هستند.
از آنجایی که کانتینرهای سندباکس به کرنل‌های user-space متکی هستند، ممکن است در مقایسه با کانتینرهای سنتی، CPU و حافظه بیشتری مصرف کنند.
برخلاف کانتینرهای استاندارد که تقریبا فوری شروع به کار می‌کنند، کانتینرهای سندباکس ممکن است به دلیل لایه مجازی‌سازی اضافه شده، کمی بیشتر طول بکشد تا بوت شوند.
خرید سرور مجازی با منابع قابل انتخاب، تحویل آنی، و کنترل کامل روی سیستم‌عامل؛ همین حالا پلن مناسب خود را انتخاب کنید.
سازمان‌هایی که از کانتینرهای سندباکس استفاده می‌کنند
در این بخش برخی از سازمان‌های برتر که از کانتینرهای سندباکس در پروداکشن استفاده می‌کنند، ارائه شده است:
- OpenAI از ران تایم gVisor برای اجرای برخی از وظایف پر ریسک خود استفاده می‌کند.
- Cloudflare از gVisor برای زیرساخت‌های building خود استفاده می‌کند.
- NVIDIA از Kata Containers برای پشتیبانی از بارهای کاری AI/ML استفاده می‌کند.
- Blink یک پلتفرم DevOps است که از gVisor برای اجرای ایمن EKS Pods استفاده می‌کند.
موارد استفاده
فرض کنید شما در حال ساخت یک پلتفرم CI/CD مبتنی بر SaaS مانند CircleCI یا BuildKite هستید، جایی که شرکتهای دیگر خطوط ساخت خود را اجرا می‌کنند.
فرض کنید این سرویس به کاربران اجازه می‌دهد مراحل ساخت خود را تعریف و هر کانتینر Docker مورد نیاز برای ساخت را اجرا کنند.
در نهایت، این کارهای ساخت به عنوان کانتینرها یا پادها در داخل کلاستر شما اجرا می‌شوند و جداسازی بین شرکت‌ها معمولا منطقی است.
در حالی که شرکت‌ها از نظر منطقی از هم جدا هستند، اما همچنان کرنل سیستم زیربنایی یکسانی را به اشتراک می‌گذارند.
حال، فرض کنید کسی در تیم شما به اشتباه privileged mode را در تنظیمات امنیتی پاد فعال می‌کند.
این بدان معناست که یک کار ساخت (build ) به خطر افتاده می‌تواند به سیستم میزبان دسترسی پیدا کند. اگر این اتفاق بیفتد، ساخت یک شرکت می‌تواند به کد سورس، اسرار یا داده‌های حساس شرکت دیگری دسترسی پیدا کند.
این یک خطر امنیتی بزرگ است!
پس چگونه از این امر جلوگیری می‌کنید؟
برای جلوگیری از چنین خطراتی، به جداسازی قوی‌تر بین بیلدها نیاز داریم. اینجاست که کانتینرهای Sandboxed وارد عمل می‌شوند.
آیا باید از کانتینرهای سندباکس استفاده کنید؟
اگر بارهای کاری حساس و چند مستاجری مانند موارد زیر را اجرا می‌کنید:
- سرویس‌های CI/CD
توابع بدون سرور (مانند AWS Lambda، Cloud Run) - پلتفرم‌های SaaS که مشتریان در آنها کد دلخواه را اجرا می‌کنند
پس کانتینرهای سندباکس راهی عالی برای به حداقل رساندن ریسک و اطمینان از جداسازی بهتر هستند.
با این حال، اگر بارهای کاری شما در یک محیط قابل اعتماد (مانند معماری میکروسرویس‌های داخلی) اجرا می‌شوند، ممکن است سربار ارزش آن را نداشته باشد.
نتیجه‌گیری
اگرچه کانتینرهای سندباکس دارای برخی از معایب عملکرد هستند، برخی از شرکت‌ها از این فناوری برای اجرای ایمن گردش کار خود استفاده می‌کنند. شرکت‌هایی که از کانتینرهای سندباکس استفاده می‌کنند، اصلاحاتی در عملکرد ایجاد کرده‌اند تا آنها را تقریبا با همان سرعت کانتینرهای معمولی کار کنند.
