خوانده و شنيده ايم كه بسياري تصور مي كنند كه كانتينرهاي 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 از بسياري جهات به تحولات سيستم لينوكس در سال 1999 شبيه است. در آن زمان هر مدير شبكه اي كه در مورد سيستم جديد و جالب لينوكس مي شنيد ، اين اقدامات را انجام مي داد:

• در اينترنت در rpmfind.net يا هر سايت ديگر كه مي توانست به دنبال پكيج اين برنامه مي گشت .

• برنامه را بر روي سيستم خود دانلود مي كرد.

• برنامه را از طريق RPM يا make install بر روي سيستم خود نصب مي كرد.

• برنامه را به عنوان يك برنامه ي ويژه و ممتاز اجرا مي كرد.

 

چه مشكلي مي توانست پيش بيايد؟

حدود دو هفته بعد ، اين مديران اخباري در مورد يك بدافزار كه برنامه ي zlib را درگير مي كند ، شنيدند و مجبور به پيگيري و بررسي صحت اين خبر شدند ؛ و با اينكه اميد داشتند و دعا مي كردند كه اين خبر صحيح نباشد ، اما در هر حال نرم افزار آنها در خطر بود.

 

اينجا بود كه Red Hat و تعدادي از همكاران مورد اعتماد آنها براي سر و سامان دادن به اوضاع وارد صحنه شدند. Red Hat امكانات زير را در اختيار مديران شبكه ها گذاشت:

• يك مرجع مطمئن براي دريافت نرم افزار تا بتوانند نرم افزارهاي مورد نياز خود را از آنجا دانلود كنند.

• يك برنامه ايمني آپديت شده تا بتوانند آسيبهاي وارده را ترميم كنند.

• يك تيم ايمني پاسخگو تا آسيبهاي وارد شده را پيدا كرده و كنترل كنند.

• تيمي از مهندسين كه بسته هاي نرم افزاري را كنترل و بررسي كنند و ايمني آنها را افزايش دهند.

• صدور گواهي Common Criteria تا ايمني سيستمهاي عامل را كنترل كنند.

 

فقط از كانتينرهاي ارائه شده از منابع مطمئن استفاده كنيد. من عقيده دارم كه بهتر است شما همچنان بسته هاي نرم افزاري و پكيج كدهاي خود را از همان منابع قبلي تهيه كنيد. اگر مطمئن نيستيد كه كدها از منابع داخلي يا خارجي مورد اعتماد به دست شما رسيده اند ، صرفاً به تكنولوژي كانتينر براي حفاظت از هاست خود اطمينان نكنيد.

 

پس مشكل چيست؟ چرا كانتينرها از سيستم محافظت نمي كنند ؟

مشكل بزرگ اين است كه سيستم لينوكس name space ندارد. در حال حاضر Docker از 5 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

• ماژولهاي كرنل

 

اگر بتوانيد به عنوان يك فرايند يا برنامه ي ويژه با يكي از اين زيرمجموعه ها يا دستگاهها ارتباط برقرار كنيد ، مي توانيد كل سيستم را در اختيار بگيريد.