مقدمه
در دنیای فناوری اطلاعات امروز، امنیت دادهها به یکی از اولویتهای اصلی سازمانها تبدیل شده است. با رشد تکنولوژی و نیاز به سامانههای پیچیده و مقیاسپذیر، پلتفرمهای مدیریت کانتینر مانند کوبرنتیز (Kubernetes) به شدت محبوب شدهاند. با این حال، مدیریت این پلتفرمها همچنین چالشهای امنیتی خاص خود را دارد. هاردنینگ به معنای تقویت امنیت سیستمها، شامل اقدامات متعددی برای محافظت از اطلاعات و زیرساختها است. در این مقاله، به بررسی روشها و بهترین شیوههای هاردنینگ کلاستر کوبرنتیز خواهیم پرداخت.
- دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
- چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
- چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
- خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
- در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
- در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
- در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
- تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
- در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
- در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
- در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
- در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
- در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
- در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
- در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
- در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
- در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
- در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
- در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
- در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
- در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
- آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
- کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمهدستی واسه تستهامون داشته باشیم.
- کامپوننتهای کوبر ( قسمت سوم ) توی این پست کامپوننتهای مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
- پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
- ورکلودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورکلود کوبر رو بررسی کردیم.
- اگه لازم شد کوبر خودش گنده میشه! ( قسمت ششم ) توی این پست در مورد سه نوع ورکلود مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.
- نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.
- استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.
- پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع probe ها توی کوبرنتیز توضیح دادیم.
- پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفتهتری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.
- اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبههای مختلف امنیت در کوبرنتیز توضیح دادیم.
- کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.
- دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روشهای مختلفی که داره توضیح دادیم و همچنین تفاوت روشهای مختلف تقسیم منابع در کلاسترها را بررسی کردیم.
- مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالشهای مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.
- هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگیها و کاربردهاش توضیح دادیم.
- سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.
- نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.
- نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.
- نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راهاندازی کنیم.
کنترل دسترسی مبتنی بر نقش (RBAC):
با استفاده از RBAC میتوانید کنترل دقیقی بر دسترسی به منابع داشته باشید. کاربران و سرویسها تنها باید دسترسی لازم برای انجام کارها را داشته باشند. همواره به این موضوع دقت کنید که دسترسی زیادی به فرد یا سرویسی نداده باشید. این نکته خیلی مهمه که توجه کنید، همانقدر که دسترسی زیادی بد میباشد دسترسی کم هم میتواند بد باشد. دسترسی باید به اندازه باشد و دسترسی درست باید به فرد، گروه یا سرویس اکانت درست متصل شده باشد.
در مثال زیر دسترسی تنها خواندنی ایجاد کردید که با استفاده از آن کاربری که بهش این role متصل میشود تنها میتواند ریسورسها رو بررسی کند و اکشن دیگری نمیتواند انجام دهد. البته این دسترسی کم نیست چون میتونه سکرتها رو ببینه و داخل آنها رو هم بررسی کنه.
سیاستهای حداقل دسترسی:
Principle of Least Privilege به معنای “اصول حداقل دسترسی” یکی از مهمترین مفاهیم امنیتی در حوزه فناوری اطلاعات است. این اصل بیان میکند که هر کاربر، برنامه یا سیستم باید به حداقل دسترسیهایی که برای انجام کار خود نیاز دارد، محدود شود. به عبارت دیگر، هر موجودیتی باید فقط آن مجوزهایی را داشته باشد که برای انجام وظایفش ضروری است و نه بیشتر و نه کمتر.
اهمیت اصل حداقل دسترسی:
- کاهش خطرات امنیتی: با محدود کردن دسترسیها به حداقل، خطر سوءاستفاده از حسابهای کاربری یا برنامهها به شدت کاهش مییابد. اگر یک کاربر یا برنامه تحت کنترل یک مهاجم قرار گیرد، دسترسی محدود آن موانع مهمی در برابر آسیبپذیریهای دیگر ایجاد میکند.
- کنترل بهتر و ردیابی فعالیتها: با تعیین دقیق دسترسیها، میتوان به راحتی فعالیتها را ردیابی کرده و از آنجایی که دسترسیها دقیقا مشخص شدهاند، عیبیابی و نظارت بر اقدامات انجام شده آسانتر خواهد بود.
- پیروی از الزامات قانونی و مقررات: بسیاری از استانداردهای صنعت و قوانین حاکم بر دادهها الزامات خاصی را در زمینه امنیت IT مشخص میکنند که به حداقل دسترسیها اشاره دارند.
- آموزش و آگاهی: افراد مختلف را در مورد اهمیت اصل حداقل دسترسی و خطرات ناشی از دسترسیهای غیرضروری آگاه کنید. شفاف سازی در مورد مسئولیتهای هر نقش و تأثیرات دسترسیهای بیمورد.
اصول حداقل دسترسی یک رویکرد حیاتی در امنیت اطلاعات است که به کاهش خطرات، بهبود کنترل و رعایت الزامات قانونی کمک میکند. با پیادهسازی مؤثر این اصل، سازمانها میتوانند نه تنها امنیت خود را بهبود بخشند بلکه از خسارتهای احتمالی ناشی از نقضهای امنیتی جلوگیری کنند. امنیت نباید یک رویکرد یکباره باشد، بلکه باید بهطور مداوم مرور، بهروزرسانی و تقویت شود.
استفاده از Namespace:
با ایجاد Namespace ها میتوانید منابع را بهطور منطقی تقسیم کنید و دسترسیها را بهطور جدی محدود نمایید. اعمال محدودیت از نظر منابع و دسترسیها کمک میکنه که تقسیمبندی خوبی ایجاد کنید. به این موضوع دقت کنید که نامگذاری مناسب استفاده کنید. از نامهای منطقی برای Namespace ها استفاده کنید که به سادگی تعیینکننده عملکرد هر کدام باشند و با مشاهده آن بتوانیم کارایی هر کدام رو متوجه بشیم.
استفاده از Network Policies برای محدود کردن ترافیک بین پادها:
یکی از ابزارهای محبوب برای بهبود امنیت در کوبرنتیز، Network Policies است. این ابزار به شما این امکان را میدهد که ترافیک شبکه بین پادها را کنترل و محدود کنید. با ایجاد سیاستهای شبکه، میتوانید مشخص کنید که کدام پادها میتوانند با یکدیگر ارتباط برقرار کنند. به صورت پیشفرض دسترسی پادها به هم کامل برقرار است. برای جلوگیری از آن میتوانید این نتورکپالیسی رو اعمال کنید که تمام دسترسیها رو بگیرد و محدود کند.
این سیاست جلوگیری از ترافیک ورودی و خروجی به کلاستر را فراهم میکند. سپس میتوانید سیاستهای خاصتری برای مشخص کردن ترافیک مجاز ایجاد کنید. هر دسترسی که لازم دارید رو اعمال کنید و دسترسی مورد نیاز را ایجاد کنید.
اهمیت بهروز نگهداشتن ایمیجهای کانتینر و استفاده از ابزارهای اسکن امنیتی:
ایمیجها از مهمترین منابع داخل کلاستر کوبرنتیز هستند. وقتی حواسمون به آنها نباشه ممکنه مخاطررات زیادی برای ما به همراه داشته باشه. با توجه و اصلاح آنها میتونیم امنیت بیشتری رو تجربه کنیم.
- بهروز نگهداشتن تصاویر: بهروز نگهداشتن ایمیجهای کانتینر بسیار مهم است، چرا که آسیبپذیریهای موجود در نسخههای قدیمی میتوانند به راحتی مورد سوءاستفاده قرار گیرند.
- استفاده از ایمیجهای معتبر: فقط از ایمیج کانتینرهایی استفاده کنید که از منابع معتبر گرفته شدهاند. به عنوان مثال، Docker Hub و سایر رجیستریهای معتبر.
- اسکن تصاویر برای آسیبپذیریها: استفاده از ابزار اسکن امنیتی به شما این امکان را میدهد که آسیبپذیریهای موجود در تصاویر خود را شناسایی کنید. از بهترین ابزارها برای این کار Trivy است که خیلی کامل هست و میتونید به راحتی از آن استفاده کنید. در ادامه به برخی از این ابزارها اشاره میکنم:
- Clair: این ابزار به توسعهدهندگان اجازه میدهد تا تصاویر کانتینر را برای آسیبپذیریها اسکن کنند.
- Trivy: یک ابزار اسکن تصاویر کانتینر که به سرعت و به طور خودکار آسیبپذیریها را شناسایی میکند.
- Anchore: این ابزار به شما امکان میدهد تصاویر کانتینر را تجزیه و تحلیل کرده و سیاستهای امنیتی را اجرا کنید.
بهروزرسانی کلاستر و نودهای کوبرنتیز:
همواره به روز رسانی اهمیت زیادی در امنیت دارد. با به روز رسانی میتونید همواره آخرین پچهای امنیتی رو دریافت کنید و هم از نظر کارایی و هم از نظر امنیت سطح بالاتری رو تجربه کنید. در بلاگپستهای قبلی به صورت کامل در مورد بهروز رسانی صحبت کردیم که توصیه میکنم حتما آنها را بررسی کنید. به روز رسانی شامل موارد زیر میشود:
- به روز رسانی خود کلاستر و ابزارهای آن
- به روز رسانی add-ons داخل کلاستر
- به روز رسانی پلاگینهای داخل کلاستر
- به روز رسانی سیستمعاملهای نودها
استفاده از رفرنسهای هاردنینگ مثل CIS
استاندارد CIS Kubernetes Benchmark: مرکز امنیت (CIS) یک استاندارد هاردنینگ توسط متخصصان امنیتی در ویرایشهای مختلف برای کوبرنتیز ارائه میدهد. با پیروی از این رفرنسها، میتوانید کلاستر خود را به روش استاندارد و قابل قبولی ایمن کنید. آزمون به وسیله ابزارهای مانند kube-bench میتواند به شما برای ارزیابی مطابقت با معیارهای CIS کمک کند. با استفاده از این استاندارد شما میتوانید از سیستمعامل تا کلاستر کوبرنتیز و سرویس داکر و موارد مختلف رو هاردن کنید. این استاندارد رفرنسی هست که سازمانهای مالی آن را معتبر میدانند و بر اساس آن استاندارد سرویسها رو تحویل میگیرند.
- ابزار kube-bench: این ابزار برای بررسی مطابقت کلاستر با معیارهای CIS طراحی شده است. با اجرای این ابزار میتوانید نقاط ضعف موجود را شناسایی و تغییر لازم را ایجاد کنید.
- ابزار Kube-hunter: ابزار Kube-hunter برای شناسایی آسیبپذیریها و نقاط ضعف امنیتی در کلاستر کوبرنتیز طراحی شده است و کاربرد دارد.
استفاده از ابزارهای Key Store برای رمزنگاری سکرتهای داخل کلاستر
همانطور که میدانید سکرتها داخل کوبرنتیز اینکریپت نیستن و به صورت encode میباشد و به راحتی میتوان آنها رو بررسی کرد. بهتر است که با استفاده از ابزارهای key store سکرتها رو encrypt کنیم.
ابزار HashiCorp Vault: استفاده از HashiCorp Vault برای مدیریت سکرتها و رمزنگاری آنها به شما این امکان را میدهد که اطلاعات حساس را به طور ایمن ذخیره و مدیریت کنید. Vault بهطور خاص برای ایجاد و نگهداری سکرتها، مانند API keys، passwords و certificates طراحی شده است.
تنظیمات امنیتی برای Ingress
ریدایرکت کردن ترافیک از HTTP به HTTPS از اهمیت بالایی برخوردار است. استفاده از nginx ingress controller یا سایر کنترلکنندهها برای ایمنسازی ترافیک ورودی به شبکه داخل کلاستر، بسیار مفید است. حتما بهش دقت کنید که این کار رو انجام بدید و تمام ترافیک ورودی به صورت TLS باشد. با استفاده از cert-manager میتونید برای تمام دامنههای خود certificate معتبر تهیه کنید با این کار امنیت بالاتری رو تو ingress تجربه میکنید. به این نکته هم دقت کنید که برای پنلها و سرویسهایی که ایجاد میکنید هم در صورت نیاز از authentication استفاده کنید.
نظارت بر لاگها:
نظارت بر لاگهای کلاستر میتواند کمک شایانی به شناسایی مشکلات امنیتی و رفتارهای غیر طبیعی کند. استفاده از ابزارهایی مانند Elasticsearch و Kibana برای مرکزیت بخشی به لاگها و تجزیه و تحلیل آنها بسیار مفید است. تحلیل لاگ Audit کوبرنتیز به شما کمک میکند تا مواردی که در کوبرنتیز اتفاق میافتد رو به خوبی بررسی و تریس کنید. این موضوع به شدت در کشف مشکل و بررسی مواردی که اتفاق افتاده موثر میباشد.
استفاده از Admission Controllers در کوبرنتیز:
Admission Controllers یکی از اجزای کلیدی و مهم در مکانیسم امنیتی و مدیریتی کوبرنتیز هستند. آنها در مرحله پردازش درخواستهای API، پس از اعتبارسنجی و تصدیق، به عنوان یک لایه میانی عمل میکنند و به شما اجازه میدهند تصمیماتی درباره تأیید، رد یا اصلاح درخواستها بگیرید.
Admission Controllers چیست؟ Admission Controllers ماژولهای مشخصی در کوبرنتیز هستند که به سادگی مدیریت و پیادهسازی سیاستها و قوانین امنیتی را در زمان ایجاد منابع جدید (PODs، Deployments، Services و …) فراهم میکنند. در واقع، اینها به عنوان فیلترهایی عمل میکنند که تمام درخواستهایی که به API سرور کوبرنتیز میرسند را بررسی میکنند.
مراحل پردازش درخواست: زمانی که یک درخواست به API سرور کوبرنتیز ارسال میشود، چندین مرحله برای پردازش آن درخواست وجود دارد:
- اعتبارسنجی: در این مرحله، درخواستهای ورودی توسط API سرور بررسی و تأیید میشوند.
- Admission: پس از تأیید، درخواست به Admission Controllers ارسال میشود. در این مرحله، Admission Controllers قوانین و سیاستها را بررسی میکنند و ممکن است درخواست را تغییر دهند، اجازه دهند یا رد کنند.
- اعمال تغییرات: درخواستهای تأیید شده نهایتاً برای ایجاد یا تغییر منابع در کلاستر اجرا میشوند.
کنترلر Mutating Admission Controllers: این کنترلرها قادر به تغییر درخواستها قبل از ایجاد یا بروزرسانی منبع هستند. برای مثال، یک کنترلر ممکن است مشخصات pod را تغییر دهد، مانند افزودن برچسبها یا تعریف فضای نام. یه جورایی با این کنترلر میتونیم داخل مانیفستها و پادها تغییرات بدیم و تغییرات داخلش اینجکت کنیم.
کنترلر Validating Admission Controllers: این نوع کنترلرها بررسی میکنند که آیا درخواست به پیادهسازی طوری انجام میشود که با قواعدی که شما تعریف کردهاید، سازگار باشد. آنها نمیتوانند درخواستها را تغییر دهند، بلکه میتوانند فقط تأیید یا رد کنند. مثلا اینکه کسی نتونه پاد با والیوم hostpath روی کلاستر ایجاد کنه.
هاردنینگ نودها:
هاردنینگ سیستمعامل خیلی مهمه و تقریبا خیلی از موضوعات مهم رو میتونیم اونجا برطرف کنیم. به این موضوع دقت کنید که اگر دسترسی به یک نود توسط فرد یا سرویسی ایجاد شود این موضوع باعث بروز مخاطرات خیلی جدی در سطح کلاستر میشود. دقت کنید هاردنینگ سیستمعامل از مهمترین موضوعاتی امنیت کلاستر و سرویسها میباشد.
-
- محدود کردن دسترسی SSH به نودها: فقط به کاربران خاص اجازه دهید که به نودها دسترسی SSH داشته باشند. بهتره که دسترسی به ssh تنها با کلید باشه و روی آیپیهای خاصی یا بهتر بگم رنج خصوصی در دسترس باشد.
- آزاد کردن پورتهای غیرضروری: تمامی پورتهای غیرضروری را بسته و فقط پورتهای مورد نیاز را در دسترس قرار دهید.
- پیکربندی فایروال: استفاده از فایروال برای کنترل ترافیک ورودی و خروجی نودهای کلاستر.
- کانفیگ کرنل لینوکس: با استفاده از کانفیگ کرنل لینوکس میتونید قابلیتهای بیشتری رو داخل لینوکس فعال کنید. با این کار میتونیم قابلیتها و کارایی سیستمعامل لینوکس رو بیشتر کنیم.
جمعبندی:
امنیت در کلاستر کوبرنتیز یک موضوع جدی و چند منظور است. با رعایت بهترین شیوهها، هاردنینگ اصولی، استفاده از ابزارهای ایمنسازی و نظارت مستمر بر وضعیت، میتوانید به یک کلاستر مطمئن دست یابید. با رویکرد صحیح و بهکارگیری تکنیکهای مناسب، میتوانید از آسیبپذیریها جلوگیری کنید و امنیت زیرساختهای خود را به حداکثر برسانید. به این نکته دقت کنید که امنیت یه فرآیند مداوم و مستمر است که باید همواره بررسی و پایش شود و با یک بار بررسی به نتایجی که مطلوب است نمیتوانید برسید.