خوانده و شنیده ایم که بسیاری تصور می کنند که کانتینر های Docker به نوعی جعبه ابزار و برنامه های کاربردی هستند – بدین معنی که تصور می کنند می توانند برنامه ها را به صورت رندوم با استفاده از Docker بر روی سیستم شان اجرا کنند.
آنها بر این باورند که کانتینر های Docker حقیقتاً می توانند از سیستم و هاست آنها محافظت کنند.
- شنیده ایم مردم می گویند که کانتینر های Docker به قدری امن هستند که گویی فرایندها را در VM و یا KVM جداگانه اجرا می کنید.
- می دانیم که برخی تصاویر رندوم را از Docker دانلود کرده و در هاست خود قرار می دهند.
- حتی دیده ایم که سرورهای PaaS ( به غیر از سرورهای OpenShift ) به کاربران خود اجازه می دهند تا عکسهای خودشان را آپلود کرده و یک سیستم چند مستأجره (multi-tenant) ایجاد کنند.
- می گویند که: ” Docker تقریباً کدهای رندوم را از اینترنت دانلود کرده و آنها را به عنوان کاربر root اجرا می کند. “
نگران شدید؟
اگر Docker را بر روی یک سیستم چند مستأجره اجرا نمی کنید و تدابیر امنیتی مناسب را برای خدماتی که در قالب یک کانتینر ارائه و اجرا می شوند ، به کار گرفته اید ، جایی برای نگرانی وجود ندارد. فقط تصور کنید فرایندها و برنامه های ویژه ای که در قالب کانتینر اجرا می شوند ، مانند همان فرایندها و برنامه های ویژه ای باشند که خارج از کانتینر اجرا می شوند.
بعضی به اشتباه تصور می کنند که استفاده از کانتینرها بهتر و سریع تر از اجرای ماشینهای مجازی است. کانتینر ها از نظر امنیتی بسیار ضعیف تر هستند ، که در ادامه ی مطلب به آن خواهیم پرداخت. اگر شما نیز با من هم عقیده هستید ، با کانتینر های Docker باید به عنوان ” یک ابزار خدمت رسانی ” برخورد شود _ به این معنی که به گونه ای با کانتینری که سرور مجازی Apache در آن اجرا می شود ، برخورد شود که گویی سرور Apache بر روی خود سیستم شما اجرا می شود . یعنی اقدامات زیر را انجام دهید:
- امتیازات ویژه را در کوتاهترین زمان ممکن حذف کنید.
- هر زمان که ممکن است برنامه های خود را به صورت non-root اجرا کنید.
- با root درون کانتینر مانند root خارج از کانتینر برخورد کنید.اینجا بود که Red Hat و تعدادی از همکاران مورد اعتماد آنها برای سر و سامان دادن به اوضاع وارد صحنه شدند. Red Hat امکانات زیر را در اختیار مدیران شبکه ها گذاشت.
در حال حاضر به همگان گفته می شود معیار استاندارد ایمنی سیستم بر اساس ارزیابی های بین المللی این است که با برنامه های ویژه ی داخل کانتینر و برنامه های ویژه ی خارج از آن یکسان برخورد شود.
تصاویر رندوم Docker را بر روی سیستم خود باز نکنید. از نظر من تحولات کانتینر Docker از بسیاری جهات به تحولات سیستم لینوکس در سال ۱۹۹۹ شبیه است. در آن زمان هر مدیر شبکه ای که در مورد سیستم جدید و جالب لینوکس می شنید ، این اقدامات را انجام می داد:
- در اینترنت در rpmfind.net یا هر سایت دیگر که می توانست به دنبال پکیج این برنامه می گشت .
- برنامه را بر روی سیستم خود دانلود می کرد.
- برنامه را از طریق RPM یا make install بر روی سیستم خود نصب می کرد.
- برنامه را به عنوان یک برنامه ی ویژه و ممتاز اجرا می کرد.
چه مشکلی می توانست پیش بیاید؟
حدود دو هفته بعد ، این مدیران اخباری در مورد یک بدافزار که برنامه ی zlib را درگیر می کند ، شنیدند و مجبور به پیگیری و بررسی صحت این خبر شدند ؛ و با اینکه امید داشتند و دعا می کردند که این خبر صحیح نباشد ، اما در هر حال نرم افزار آنها در خطر بود.
اینجا بود که Red Hat و تعدادی از همکاران مورد اعتماد آنها برای سر و سامان دادن به اوضاع وارد صحنه شدند. Red Hat امکانات زیر را در اختیار مدیران شبکه ها گذاشت:
- یک مرجع مطمئن برای دریافت نرم افزار تا بتوانند نرم افزارهای مورد نیاز خود را از آنجا دانلود کنند.
- یک برنامه ایمنی آپدیت شده تا بتوانند آسیبهای وارده را ترمیم کنند.
- یک تیم ایمنی پاسخگو تا آسیبهای وارد شده را پیدا کرده و کنترل کنند.
- تیمی از مهندسین که بسته های نرم افزاری را کنترل و بررسی کنند و ایمنی آنها را افزایش دهند.
- صدور گواهی Common Criteria تا ایمنی سیستمهای عامل را کنترل کنند.
فقط از کانتینرهای ارائه شده از منابع مطمئن استفاده کنید. من عقیده دارم که بهتر است شما همچنان بسته های نرم افزاری و پکیج کدهای خود را از همان منابع قبلی تهیه کنید. اگر مطمئن نیستید که کدها از منابع داخلی یا خارجی مورد اعتماد به دست شما رسیده اند ، صرفاً به تکنولوژی کانتینر برای حفاظت از هاست خود اطمینان نکنید.
پس مشکل چیست؟ چرا کانتینرها از سیستم محافظت نمی کنند ؟
مشکل بزرگ این است که سیستم لینوکس name space ندارد. در حال حاضر Docker از ۵ namespace برای تغییر و جایگزینی نمایش فرایندها در سیستم استفاده می کند : Process, Network, Mount, Hostname, Shared Memory
با اینکه این امر می تواند نوعی ایمنی نسبی برای کاربر ایجاد کند ، اما این ایمنی به اندازه ی ایمنی ایجاد شده در KVM جامع نیست. در محیط KVM هیچگاه فرایندها و برنامه های در حال اجرا در ماشین مجازی در ارتباط مستقیم با مرکز هاست نیستند. هیچ یک از این برنامه ها و فرایندها به فایلهای سیستمی مانند /sys ، /sys/fs و /proc/ دسترسی ندارند. در این محیط node دستگاه با مرکز KVM مرتبط است نه هاست. بنابراین برای اینکه یک فرایند یا برنامه بتواند در VM امتیاز ویژه داشته باشد ، باید بتواند از مرکز VM گذشته ، نقطه ی آسیب پذیر HyperVisor را یافته ، از سد کنترل های SELinux که در VM بسیار محکم هستند، عبور کرده و سرانجام به مرکز هاست حمله کند.
زمانی که برنامه ای را در کانتینر اجرا می کند ، درست مثل این است که در ارتباط مستقیم با هسته ی هاست هستید.
زیر مجموعه های اصلی هسته ی هاست( موارد زیر) namespace نیستند:
- SELinux
- Cgroups
- فایلهای سیستمی زیر مجموعه ی /sys
- /proc/sys ، /proc/sysrq-trigger ، /proc/irq ، /proc/bus
دستگاههای زیر نیز namespace نیستند :
- /dev/mem
- ابزارهای فایلهای سیستمی /dev/sd
- ماژولهای کرنل
اگر بتوانید به عنوان یک فرایند یا برنامه ی ویژه با یکی از این زیرمجموعه ها یا دستگاهها ارتباط برقرار کنید ، می توانید کل سیستم را در اختیار بگیرید.