توی این پست یه مقدار در مورد امنیت توی داکر صحبت میکنم و بعدش میرم سراغ یه سری بست پرکتیس‌ها و تجربه‌هایی که خودم توی کار با این ابزار داشتم. بعد از این پست میریم سراغ ابزارهای دیگه و یه جورایی میشه گفت فعلا آخرین پستمون در مورد داکر میشه، همین پستی که الان دارید میخونید!
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
توی چهار حوزه اصلی امنیت داکر رو میشه بررسی کرد:
به صورت کلی ما یه مبحثی تحت عنوان کانتینر سکیوریتی داریم که به امنیت در کانتینرها و زیرساخت‌های آنها می‌پردازد. این موضوع فارغ از داکر برای هر سرویسی که کانتینر ایجاد می‌کند صادق است. اینجا سعی میکنم که به صورت مختصر اشاره‌ای به موضوع امنیت و موارد پیرامون آن داشته باشم. حتما می‌دونید و نیازی نیست که بیشتر توضیح بدم امنیت خیلی مهمه. اونقدر مهم که میتونه موجودیت سرویس ما رو تحت شعاع قرار بده. یعنی میتونه کل سرویس رو نابود کنه. پس باید بهش دقت کنیم و برای اون برنامه داشته باشیم.
با توجه به اینکه کانتینرها از کرنل لینوکس به صورت مشترک استفاده می‌کنند. اگر یکی از کانتینرها دچار مشکل امنیتی شود این امکان وجود دارد که کرنل لینوکس هاست و کانتینرهای دیگه‌ای که روی آن هستند نیز دچار مشکل شوند. همین طور اگر ایمیج‌هایی که استفاده می‌شود آسیبپذیری امنیتی داشته باشند نیز این امکان وجود خواهد داشت که این آسیبپذیری روزنه‌ای برای ورود به سمت کانتینرهای دیگه و کرنل لینوکس هاست باشد. از این رو بررسی و پایش امینت کانتینرها خیلی اهمیت داره. در ادامه به برخی از موارد مهم کانتینر سکیوریتی اشاره میکنم.
همواره یکی از مهمترین مواردی است که به راحتی می‌توان آن را انجام داد. بررسی و پایش آسیب‌پذیری‌های امنیتی در زمان ایجاد ایمیج و سپس در زمان استفاده از آنها به صورت کانتینر که میتونه جلوی بروز خیلی از مشکلات رو بگیره. ابزارهای زیادی برای این کار وجود داره که من خودم Trivy رو پیشنهاد میکنم که برای aquasecurity است که خیلی ابزار خوب و قابل اعتمادیه. به راحتی میتونیم با استفاده از اون ایمیج‌ها، کانتینرها، فایل‌سیستم‌ها و حتی داکرفایل‌های خودمون رو بررسی و پایش کنیم. یه نکته‌ی مهم اینکه ما میتونیم قسمت و مرحله‌ای از پایپ‌لاین ساخت ایمیج خودمون رو به Security Scan اختصاص بدیم و با استفاده از آن ایمیج‌هایی که ایجاد می‌کنیم رو به صورت خودکار همواره اسکن و پایش کنیم. خوبه که بدونیم و حواسمون بهش باشه که ما باید رجیستری خودمون که ایمیج‌ها رو داخل آن نگهداری می‌کنیم رو هم به صورت منظم و طبق برنامه پایش و بررسی کنیم.
یکی از نکات مهم تو ساخت ایمیج اینه که ما تا جایی که میتونیم ایمیج‌های کوچیک‌تری ایجاد کنیم. مالتی‌استیج یک روش بسیار مناسب برای این کار است. تعداد ابزار و اپلیکیشن کمتر امکان آسیبپذیری کمتری را به همراه خواهد داشت. این فکت خیلی ساده‌ای هست. هر چقدر تعداد اپلیکیشن کمتری داشته باشیم به همون نسبت احتمال حمله‌ی کمتری رو هم خواهیم داشت. به این نکته خیلی دقت کنید. البته این موضوع رو ما تو سرورهای لینوکس هم رعایت می‌کنیم و سعی می‌کنیم که همواره تعداد اپلیکیشن و ابزار کمتری روی سرور داشته باشیم یا به عبارت دیگه هر چیزی که می‌خواهیم نصب کنیم دلیل مشخص و موجهی برای آن خواهیم داشت. یکی از موضوعات مهم دیگه اینکه از ایمیج‌هایی استفاده کنیم که منبع آن برای ما مشخص و مورد تایید است. گرفتن ایمیج از منابع متفرقه می‌تواند مخاطرات زیادی رو برای ما به همراه داشته باشد.
یکی از نکات مهم تو کانتینر سکیوریتی امنیت سرور لینوکسی هست که داکر روی آن نصب و پیکربندی شده. اگر امنیت آن سرور پایین باشه مخاطرات زیادی رو برای ما ایجاد میکنه و سرویس‌ها و اپلیکیشن‌‌هایی که روی آن ایجاد کردیم رو تو وضعیت خطر قرار میده. کسی که به سرور لینوکس ما دسترسی داشته باشه و بتونه به سرویس داکر هم دسترسی پیدا کنه میتونه به تمامی کانتینرهای ما دسترسی کامل داشته باشه. این نکته‌ی خیلی مهمی است که باید همواره هاردنینگ (مجموعه اقداماتی که باعث افزایش امنیت سرور ما می‌شود) رو جدی بگیریم و کاری کنیم که سرور لینوکس ما امن‌تر باشد.
یه چند سالی هست که من سعی میکنم سرویس یا پروسه‌ای به جز روی داکر بالا نداشته باشم. یعنی هر چیزی که باشه حتما داکرایزش میکنم. معمولا تحویل ما به این صورت است که پروژه رو همراه با داکرفایل به همراه HLD کامل پروژه تحویل می‌گیرم. اگر تیم توسعه هم نتونه داکرفایل رو بنویسه خودمون کمکشون می‌کنیم و داکرفایل رو می‌نویسیم. حالا ما چی داریم داکرفایل که نحوه‌ی بالا آمدن سرویسمون رو نشون میده و HLD که نحوه‌ی ارتباط سرویس‌ها با هم به همراه موارد دیگه‌ای همانند دیتابیس‌ها و … هستش. مابقی موارد مثل دیتابیس‌ها، کش‌ها، کیوها و … رو هم به صورت داکری بالا میاریم. تو داکرایز کردن پروژه‌ها حتما به موارد زیر دقت کنید:
سال ۱۳۹۷ بود که داکرمی رو ایجاد کردم. سایتی که توی اون به آموزش داکر می‌پرداختم و هم ویدئو داشت و هم بلاگ پست می‌نوشتم. خیلی دوستش دارم. کلی براش زحمت کشیدم و تو زمینه‌ی داکر یکی از اولین منابع هست که می‌تونم بهتون معرفی کنم. البته یکم بعدش خیلی بی‌حوصله شدم و رها کردم همه چیز رو و وضعیت سایت بهم ریخت که الان دوباره داریم براش وقت میذاریم و درستش می‌کنیم که بهتر بشه.
طی این چند ساله خیلی پیش اومده که برای سازمان‌ها و شرکت‌های مختلف داکر آموزش بدم. در کنار اسلاید‌های آموزشی نیاز داریم که تمرین داشته باشیم و سناریو انجام بدیم تا مواردی که آموزش دیدیم رو به صورت کارگاهی فرا بگیریم. این پروژه کلی سناریو و سمپل داره که بهتون کمک میکنه تا داکر رو بهتر یاد بگیرید و تمرین کنید.
به نظرم این دو تا کتاب خیلی خوبه و میتونه کلی بهتون کمک کنه. کتاب Docker Up and Running و کتاب Docker in Action که تو هر دو تا کتاب داکر رو به خوبی شرح و بسط دادن. البته حتما سایت خود داکر رو هم ببینید که کامل تمام موارد رو توضیح داده و میتونه بهترین مرجع برای کار با داکر باشه.
تقریبا از سال ۹۷ دارم با داکر کار میکنم و خیلی موارد زیادی رو تو این مدت تجربه کردم. خیلی موارد هست که شاید از حوصله خارج باشه. اینجا چند تا موضوع رو بهش می‌پردازم که میتونه نکات خوبی داشته باشه.
این یه قاعده‌ی خیلی باحالی هست. ما با کانتینرهای خودمون به صورت Cattle یعنی مثلا گاو یا گوسفند یا به صورت کلی دام رفتار می‌کنیم. یعنی وقتی طوری بشه مثلا پاش بشکنه دیگه نمی‌بریمش درمانگاه تا پاش رو کچ بگیریم و درمانش کنیم یا عملش کنیم. تو این طور مواقع اون رو می‌فرستیم به سمت کشتارگاه! شاید یکم خشن و بی‌رحم به نظر برسه ولی قاعده‌ی دامداری اینو می‌گه. ولی اگر همین اتفاق برای Pet ما بیافته نه تنها پاش رو گچ می‌گیریم بلکه کلی هم هزینه می‌کنیم تا اگر نیاز باشه عمل خوبی انجام بشه که بتونه دقیقا به زندگی عادیش برگرده. تفاوت این دو تا نگاه خیلیه. تو مدیریت و نگهداری کانتینرها ما همانند Cattle با آنها رفتار می‌کنیم. اگر دچار مشکل بشه آن رو پاک می‌کنیم و یه کانتینر دیگه ایجاد می‌کنیم. اینجا منطق ما اینه که هر آن چیزی که این کانتینر از روی آن بالا آمده داخل ایمیج است و اگر به دیتایی هم نیاز داشته باشه داخل والیوم است. برای همین به راحتی میتونیم State قبلی خودمون رو داشته باشیم و بتونیم روی آن برگردیم.
تو خیلی از پروژه‌ها ما از مدیریت لاگ مرکزی استفاده می‌کنیم. یعنی یه سامانه‌ی لاگینگ داریم که لاگ‌ها رو به سمتش می‌فرستیم. معمولا این سرویس‌ها درایور برای داکر دارند که با استفاده از آن میتونیم لاگ‌ها رو به راحتی سمت لاگینگ مرکزی بفرستیم. معمولا من از Grafana Loki استفاده میکنم و درایور اون رو هم برای داکر نصب و کانفیگ میکنم. این طوری تمام کانتینرهام لاگ‌هاشون رو سمت سرویس لوکی می‌فرستند. حالا این وسط اگر اختلالی برای نتورک یا سرویس لاگینگ من ایجاد بشه تمام داکر دیمن‌های من کند می‌شوند و به مشکل می‌خورند. برای جلوگیری از این مشکل بهتره که به جای استفاده از درایور لوکی از خود Promtail استفاده کنیم که لاگ‌ها رو بفرسته و از روی فایل بخونه. این طوری شاید پرفورمنس کمتری داشته باشه چون داره از روی فایل می‌خونه ولی در زمان بروز مشکل برای لاگینگ یا نتورک، دیگه سرویس داکر من رو از کار نمی‌اندازه و کارایی اون رو مختل نمی‌کنه.
قبلا هم گفتم حتی اگر تو پروژه‌ای داکرایز کردن جزو استپ‌های پروژه نباشه باز من حتما داکرایزش میکنم. این کار خیلی تو نگهداری سرویس و ایجاد CI/CD برای اون به من کمک میکنه. نگهداری رو خیلی برام ساده‌تر میکنه چون طبق همون قاعده‌ی Cattle not Pets به راحتی می‌تونم State قبلیم رو مجدد از روی ایمیج ایجاد کنم و زمان رفع مشکلم رو خیلی کاهش میده و هم می‌تونم به خوبی نسخه گذاری کنم و در صورت امکان و نیاز تغییراتم رو به صورت بدون وقفه اعمال کنم. تو CI/CD هم ما نیاز داریم که State قبلی خودمون رو کلین کنیم تا بتونیم State جدید رو جایگزین آن کنیم. وقتی داکرایز کرده باشیم این اتفاق به خوبی انجام میشه و میتونیم به راحتی با تغییر ایمیج‌ها استیت‌هایی که لازم داریم رو ایجاد کنیم و یا بریم روی State مد نظر خودمون.
داکرفایل یکی از مهمترین مواردی است که باید تو این اکوسیستم بهش دقت کنیم. با استفاده از داکرفایل میتونیم ایمیج‌های خودمون رو آماده کنیم. تو ایجاد داکرفایل کلی آیتم هست که اگر بهشون دقت کنیم میتونیم ایمیج درستی رو آماده کنیم. مثلا اینکه باید دقت کنیم که حتما ایمیج‌هامون Rootless باشند یا اینکه وقتی دستور kill برای آنها ارسال میشه کانتینر و پروسه‌ی داخل آن به چه صورت بمیرد. کلی موضوع دیگه هست که با رعایت آنها میتونیم ایمیج درستی آماده کنیم که باعث میشه به خوبی سرویس رو نگهداری و پایش کنیم. تو داکرفایل و استفاده درست از قابلیت‌های آن میتونیم به خوبی سرویس‌های خودمون رو ایجاد و مدیریت کنیم تقریبا می‌تونم بگم که اکثر مشکلات ما تو مدیریت کانتینرها بر می‌گرده به ایمیج آن که به درستی ایجاد نشده.
کامپوزفایل بهترین راه برای ایجاد کانتینر از روی ایمیج است. ما تو کامپوزفایل نحوه‌ی بالا اومدن کانتینر به همراه نتورک و والیوم و تمام مواردی که نیاز داریم رو مشخص می‌کنیم. یعنی به صورت کامل تمام سناریوی که لازم داریم تا ایمیج به کانتینر تبدیل شود و بالا بیاید رو می‌نویسم. تمام ارتباطات آن به همراه کان فیگ‌ها و … که نیاز دارد رو تو همون کامپوزفایل قرار می‌دهیم. این طوری تمام مسیر ما به صورت کد خواهد بود. ساخت ایمیج‌ها با استفاده از داکرفایل و بالا آمدن کانتینرها با استفاده از کامپوز فایل خواهد بود. تمام مسیر به صورت کد می‌باشد و کاملا قابل تکرار خواهد بود. همواره سعی کنید که یک کامپوز کامل داشته باشید که با استفاده از آن بتونید سرویس‌های خودتون رو تو محیط‌های مختلف به راحتی ایجاد کنید و بالا بیارید. دقت کنید همواره از یک ایمیج تو تمام محیط‌های خود استفاده کنید و یک کامپوز داشته باشید که با استفاده از وریبل‌های متفاوت سرویس خودتون رو به صورت متفاوت تو محیط‌های مختلف بالا بیارید. یک ایمیج و یک کامپوز با وریبل‌های مختلف در محیط‌های مختلف، این یک روش خیلی خوبی است و بسیار توصیه می‌شود.
هر پروژه‌ای بدون اتومیشن و کلاسترینگ اصلا نمی‌تونه بزرگ بشه. برای بزرگ شدن و پاسخ به درخواست‌های زیاد نیاز داریم که سمت کلاسترینگ بریم و اتومیشن یکی دیگه از ملزومات آن خواهد بود. براتون یه مثالی می‌زنم. چند سال پیش که کرونا بود نمایشگاه کتاب می‌خواست به صورت آنلاین برگزار بشه. اولین بارش بود و کلی هم براش تبلیغات رفته بودن. نتیجه‌ی این دو تا موضوع این شد که ما ترافیک خیلی عجیب و غریبی رو تجربه کردیم. ساعت ۱۰ صبح نمایشگاه شروع می‌شد ولی ما از ۹ صبح کاملا Down بودیم. یک ساعت قبل از شروع عملکرد سایت بهم ریخته بود و به درستی سرویس نمی‌داد. چند تا موضوع بود که منو تو اون رخداد نجات داد. اول اینکه تمام سرویس‌ها داکرایز بود. این موضوع کمک می‌کرد که بتونم به خوبی آنها رو اسکیل کنم و تغییر بدم. اگر تغییری هم برام مطلوب نبود به راحتی بتونم برگردم به استیت قبلی خودم. موضوع دوم که خیلی بهم کمک کرد اتومیشن بود. برای همه کارهایی که می‌خواستم انجام بدم اتومیشن داشتم تو زمان‌هایی که باید اسکیل می‌کردم و خیلی وضعیت خوبی نداشتم چون تقریبا ۳۰ الی ۴۰ ساعت بود که مداوم کار کرده بودم و نخوابیده بود، به درستی تونستم کارم رو پیش ببرم و انجام بدم. موضوع سوم هم کلاسترینگ بود که با استفاده از آن سرویسم رو به خوبی اسکیل کردم. نکته‌ی مهم این بود که از قبل ساختار درست و استانداردی رو ایجاد کرده بودم و تو زمان وقوع رخداد به دادم رسید و تونستم با استفاده از آن سرویس خودم رو اسکیل کنم و بتونم اون ایونت رو به خوبی طی کنم. اگر این موارد رو انجام نداده بودم اون پروژه کاملا از دست می‌رفت. البته جا داره بگم که داشتن مشاور خیلی مهمه و برای مواقع حساس میتونه راهگشا باشه. کسی که دانش و تجربه‌ی بالایی داره و میتونه با راهکارهایی که ارائه میده زمین بازی رو عوض کنه. تو این ایونت حضور دوست و استاد عزیزم آقای حسین آیت کنارم خیلی موثر بود و اگر نبود می‌دونم که به سلامت این ایونت رو نمی‌تونستم طی کنم.
تو پروژه‌های داکرایزی حضور میرور رجیستری و یا بهتر بگم راهکار درست دریافت ایمیج یکی از موارد مهمی است که باید بهش دقت کنیم و براش راه حلی داشته باشیم. من خودم پیشنهادم استفاده از nexus هست که خیلی میتونه کمک کنه. از nexus میتونیم به صورت mirror registry و repository استفاده کنیم. یعنی هم برای ریپوهای apt و python و … هم برای ایمیج‌های داکرمون کاربرد داره. بعدا هم که می‌خوایم سمت کوبرنتیز بریم برای اون موضوع هم میتونه خیلی بهمون کمک کنه. به صورت کلی شما باید یه راهکار درست و دائمی برای دریافت ایمیج‌های خودتون داشته باشید که بتونید به راحتی از تحریم‌هایی که صورت گرفته عبور کنید.
این میشه پست آخر داکرمون فعلا و در ادامه مسیر به سراغ ابزارهای بعدی میریم. امیدوارم بعدا بتونیم باز برگردیم و توی داکر بیشتر عمیق شیم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
