معماریهای کانتینری امنیت سیستمعامل را حذف نکردهاند؛ آن را از یک لایهٔ مستقل به بخشی از زنجیرهای پیچیدهتر تبدیل کردهاند. بارهای کاری کوتاهعمر میشوند، برنامه و وابستگی در image قرار میگیرند، runtime و ارکستریتور میان سامانه و سرویس مینشینند و تصمیمهای زمان اجرا بهاندازهٔ تصمیمهای زمان ساخت اهمیت پیدا میکنند.
در این معماری، سیستمعامل میزبان دیگر محل اجرای مستقیم همهٔ برنامهها نیست؛ بستر اعتماد و کنترل برای تمام لایههای بالاتر است. هر ضعفی در کرنل، درایور، runtime یا سیاست میزبان میتواند همزمان چندین بار کاری را تحت تأثیر قرار دهد. بنابراین کانتینر یک مرز امنیتی مستقل از سیستمعامل نیست.
ماشین مجازی و کانتینر، دو نوع جداسازیاند
ماشین مجازی یک سامانهٔ مستقل با کرنل، چرخهٔ بوت و سیستمعامل مهمان خود دارد. این استقلال مرز روشنتری میسازد، اما در مقابل منابع بیشتر مصرف میکند و تعداد سیستمعاملهایی را که باید وصله، پایش و اداره شوند افزایش میدهد.
کانتینر محیط اجرای ایزولهٔ یک برنامه است که مستقیماً روی کرنل میزبان اجرا میشود. برنامه، کتابخانه و وابستگیهای لازم را همراه دارد، اما کرنل مستقل ندارد. جداسازی فرآیند، فایلسیستم، شبکه و منابع با قابلیتهای بومی هستهٔ لینوکس انجام میشود.
اشتراک کرنل هم مزیت است و هم نقطهٔ تمرکز ریسک. کانتینرها سبکترند و میتوانند سطح حملهٔ فضای کاربر را کاهش دهند، اما شکست جداسازی یا آسیبپذیری کرنل مرز میان بارهای کاری را تضعیف میکند. در محیط حساس، بحث کانتینر بدون بحث میزبان ناقص است.
توزیع داخل کانتینر با توزیع میزبان یکی نیست
میزبان میتواند یک توزیع سازمانی پایدار و سختسازیشده باشد، در حالی که کانتینر از Alpine، یک user-space دیگر یا image نوع Distroless استفاده کند. آنچه کانتینر «سیستمعامل» مینامد، مجموعهٔ کتابخانهها و ابزارهای فضای کاربر است؛ کرنل همچنان از میزبان میآید.
این جدایی اجازه میدهد لایهٔ کاربرد چابک بماند و لایهٔ زیرساخت با چرخهای محافظهکارانهتر اداره شود. image بدون shell و ابزار مدیریتی، مسیرهای سوءاستفاده پس از نفوذ را کم میکند. اما اگر برنامه به GPU، ماژول کرنل یا قابلیت خاص سختافزاری نیاز داشته باشد، وابستگی میان image، runtime، درایور و میزبان دوباره پررنگ میشود.
تغییرناپذیری رانش را حذف نمیکند؛ جابهجا میکند
در مدل درست کانتینری، نمونهٔ در حال اجرا نگهداری نمیشود. تغییر برنامه یا وابستگی باید image تازهای بسازد و نمونهٔ قبلی جایگزین شود. کانتینری که درون آن اصلاح دستی انجام شده، دیگر مرجع معتبر نیست و نباید باقی بماند.
این منطق بخش بزرگی از رانش پیکربندی در سطح بار کاری را حذف میکند. دو نمونه از یک image باید یکسان باشند و بدافزاری که روی فایلسیستم موقتی ماندگار شده، با جایگزینی نمونه از بین برود. اما ریسک به مرحلهٔ ساخت منتقل میشود. اگر image پایه آلوده، وابستگی آسیبپذیر یا پیکربندی نادرست باشد، تغییرناپذیری همان خطا را با سرعت و مقیاس بیشتری تکثیر میکند.
بنابراین وضعیت معتبر باید در کل زنجیره تعریف شود: Dockerfile یا دستور ساخت، image پایه، وابستگیها، امضا، SBOM، رجیستری، سیاست استقرار و پیکربندی زمان اجرا. ثبات قابل اثبات و بازگشت در کانتینر به معنای توان بازتولید image سالم است، نه نگهداری طولانی یک نمونهٔ ظاهراً پایدار.
مرزهای واقعی در کرنل میزبان
Namespace دید هر بار کاری به فرآیند، شبکه، mount و کاربران را محدود میکند. Cgroup مصرف CPU، حافظه و سایر منابع را کنترل میکند. Linux capabilities اختیار یکپارچهٔ root را به قابلیتهای کوچکتر میشکند. Seccomp فراخوانیهای مجاز سیستم را محدود میسازد و SELinux یا AppArmor میتوانند رفتار فرآیند را با سیاست اجباری مهار کنند.
هیچیک از این سازوکارها بهتنهایی مرز کامل نیستند. امنیت از همپوشانی آنها شکل میگیرد:
- کانتینر تا حد ممکن با کاربر غیر root اجرا شود؛
- capabilities غیرضروری حذف شوند؛
- اجرای privileged و mountکردن مسیرهای میزبان استثنایی باشد؛
- سوکت مدیریتی runtime در دسترس بار کاری قرار نگیرد؛
- seccomp و LSM فعال و قابل ممیزی باشند؛
- ماژولها و سطح حملهٔ کرنل میزبان محدود شوند؛
- و میزبان چرخهٔ وصله و بازگشت مشخص داشته باشد.
اگر runtime یا سوکت مدیریتی با دسترسی گسترده در اختیار کانتینر قرار گیرد، بحث «امنیت کانتینر» عملاً بیمعنا میشود؛ زیرا بار کاری میتواند مرز اعتماد میزبان را بازتعریف کند.
زنجیرهٔ تأمین از بسته به image گسترش یافته است
Image ممکن است کد سازمان، صدها وابستگی متنباز، ابزار build و لایههای بهجامانده از مراحل قبلی را در خود داشته باشد. اسکن آسیبپذیری فقط یکی از کنترلهاست. سازمان باید منشأ image پایه، digest دقیق، امضای سازنده، SBOM و مجوز ورود به رجیستری عملیاتی را کنترل کند.
اصل مهم این است که «ساختهشدن موفق» معادل «مجازبودن برای استقرار» نیست. image باید در محیط جدا ساخته شود، بدون دریافت رازهای تولید آزموده شود، خروجی آن امضا گردد و admission policy فقط artifact تأییدشده را بپذیرد. در محیط ایزوله، رجیستری داخلی همان نقشی را دارد که مخزن بستهٔ داخلی برای سیستمعامل ایفا میکند.
امنیت زمان اجرا و eBPF
پیش از اجرا میتوان image را اسکن و سیاست را بررسی کرد، اما رفتار واقعی تنها در runtime دیده میشود. اجرای shell غیرمنتظره، دسترسی به فایل حساس، اتصال شبکهای جدید یا افزایش ناگهانی مصرف منابع ممکن است نشانهٔ نفوذ باشد.
eBPF امکان مشاهده و اعمال سیاست در سطح کرنل را بدون افزودن عامل سنگین به هر کانتینر فراهم میکند. این قابلیت میتواند syscall، ارتباط شبکه و رفتار فرآیند را ببیند و با وضعیت مورد انتظار مقایسه کند. مزیت اصلی آن دید مشترک از میزبان و بارهای کاری است؛ همان نقطهای که مرز واقعی اجرا قرار دارد.
این قدرت باید با حاکمیت همراه باشد. برنامهٔ eBPF نیز کد سطح پایین و پرقدرت است و مجوز بارگذاری، منشأ و رفتار آن باید کنترل شود. ابزار دفاعی بدون کنترل تغییر میتواند خودش بخشی از سطح حمله شود.
شبکه باید بر هویت متکی باشد، نه مکان
در معماری کانتینری، IPها موقتیاند و «داخل شبکه» مرز باثباتی نیست. ارتباط نباید فقط به دلیل حضور دو سرویس در یک subnet مجاز باشد. هر سرویس باید هویت دیجیتال خود را اثبات کند و سیاست مشخص سازد با چه سرویسی و برای چه هدفی ارتباط دارد.
در الگوی مبتنی بر mTLS و Service Mesh، هر دو طرف ارتباط هویت یکدیگر را تأیید میکنند و ترافیک رمز میشود. ریزقطعهبندی مبتنی بر هویت، حرکت جانبی را محدود میکند؛ حتی اگر مهاجم به یک کانتینر رسیده باشد. ابزارهایی مانند Cilium میتوانند بخشی از شبکه و سیاست را با eBPF در سطح کرنل اعمال کنند، اما اصل مهمتر از ابزار است: اعتماد باید به هویت و مجوز گره بخورد، نه آدرس.
اسرار نباید بخشی از image باشند
هاردکدکردن رمز عبور، کلید API یا گواهی در image، یک راز را به شیئی تکثیرپذیر تبدیل میکند. آن راز در رجیستری، محیط آزمون، نسخهٔ پشتیبان و هر کپی image پخش میشود. حتی حذف آن در لایهٔ بعدی لزوماً داده را از لایههای قبلی image پاک نمیکند.
در معماری تغییرناپذیر، راز بخشی از پیکربندی ثابت نیست. راز باید در زمان اجرا، برای هویتی مشخص، با عمر محدود و ترجیحاً در حافظه تحویل شود. سامانهای مانند Vault یا راهکار معادل، راز را رمزشده نگه میدارد و بر اساس هویت و سیاست در اختیار مصرفکننده میگذارد. کانتینر مالک راز نیست؛ مصرفکنندهٔ موقت آن است.
کانتینر امن یا ناامن نیست؛ معماری آن چنین است
کانتینر محل اعمال اعتماد را تغییر میدهد: از سرور به image، از نمونهٔ پایدار به artifact بازتولیدپذیر و از مرز شبکه به هویت سرویس. اگر image، زنجیرهٔ ساخت، runtime و میزبان در یک چرخهٔ کنترلشده قرار نگیرند، این جابهجایی فقط پیچیدگی را افزایش میدهد.
سختسازی کرنل، انتخاب توزیع میزبان، مدیریت وصله، سیاست LSM، کنترل runtime و مشاهدهپذیری، پیشنیاز امنیت کانتینرند. این موضوع برای بارهای کاری GPU و AI حساستر نیز میشود، زیرا زنجیرهٔ میزبان به درایور و شتابدهنده ادامه پیدا میکند؛ موضوع مقالهٔ امنیت زیرساخت هوش مصنوعی از کرنل و GPU آغاز میشود.