توسعه دهندگان از Kubernetes به عنوان ابزار استاندارد برای ارکستراسیون کانتینر استفاده می کنند، زیرا نرم افزار منبع باز به طور ایده آل از کار با میکروسرویس ها و سازماندهی تیم های چابک پشتیبانی می کند. از آنجایی که Kubernetes بسیار ارزشمند است، سیستم های مورد استفاده به یک هدف محبوب برای هکرها تبدیل شده اند. پلتفرم های Kubernetes، مانند سایر برنامه های کاربردی ابری یا سیستم های محلی، نیز کاملاً ایمن نیستند. اقدامات زیر نشان می‌دهد که چگونه مدیران و توسعه‌دهندگان سیستم می‌توانند از کانتینرهای یک برنامه به بهترین شکل ممکن در برابر حملات و بدافزار در Adacor محافظت کنند، مشتریان ما این سؤال را مطرح کردند: آیا محفظه‌هایی وجود دارند که به حقوق ریشه نیاز دارند؟ یک کانتینر با حقوق ریشه یک تهدید بالقوه برای حملات است! اگر یک هکر بتواند این کانتینر یا این برنامه را به خطر بیاندازد، می تواند سایر برنامه ها و داده ها را از طریق حقوق ریشه دستکاری کند. در بدترین حالت، کل خوشه تحت تأثیر قرار می گیرد. به همین دلیل است که مدیران اگر فقط به طور استثنایی نرم‌افزار را در کانتینرهایی با حقوق ریشه ارائه دهند – یعنی فقط در مواقعی که کاملاً ضروری است. سپر شود مشابه سرورهای فیزیکی یا ماشین‌های مجازی (VM)، تنها جداسازی مؤثر منابع از حملات جلوگیری می‌کند. کانتینرهایی که روی هاست کار می کنند این مزیت را دارند که خدمات کوچک تری ارائه می دهند و پتانسیل قابل توجهی برای صرفه جویی در منابع ارائه می دهند. برنامه‌های کاربردی ابری که به‌عنوان میکروسرویس راه‌اندازی می‌شوند، از ظروف سبک وزن، اما فقط به طور محدود ایزوله بهره می‌برند. ریسک باید به صورت جداگانه برای هر برنامه سنجیده شود: آیا VMهای سنگین و پررونق شامل می شوند یا اگر حقوق ریشه تا حد زیادی از بین رفته است. دقت
وقتی صحبت از امنیت به میان می آید، به نظر همه کاربران نرم افزار می رسد: همیشه از آخرین نسخه استفاده کنید! آیا این راه حل ایده آل برای پروژه ای در حال توسعه پویا مانند Kubernetes است؟ به‌طور میانگین چند بار به‌روزرسانی نسخه وجود دارد؟ انجمن Kubernetes هر سه ماه یک نسخه جدید منتشر می کند. سه نوع به‌روزرسانی
- به‌روزرسانی‌های اصلی
- به‌روزرسانی‌های جزئی
- وصله‌ها
به توسعه‌دهندگان توصیه می‌شود
509 509 به دقت خوانده نشوند. به روز باشد لزوماً لازم نیست فوراً با نسخه صفر یک به‌روزرسانی اصلی یا فرعی همراه باشید. شروع با نسخه x.x.1 کافی است تا مطمئن باشید و تعداد زیادی پچ مفید را با خود ببرید. اگر یک نسخه فرعی به‌روزرسانی شده منتشر شود، حداکثر دو نسخه فرعی قبلی پشتیبانی می‌شوند.
اقدام 3: تنظیم واضح احراز هویت و مجوز
کنترل‌های دسترسی مبتنی بر نقش یکی از مهم‌ترین جنبه‌های امنیتی در Kubernetes هستند. پس از احراز هویت یک کاربر، API مجوزها را با استفاده از مدل Role Based Access Control (RBAC) یکپارچه شده در Kubernetes تعیین می کند. بسته به مجوز، کاربران می توانند منابع Kubernetes را ایجاد، خواندن، به روز رسانی یا حذف کنند. این سیستم بین حساب های کاربری و خدمات تفاوت قائل می شود. به دلیل درجه بالای اتوماسیون در فناوری کانتینر، کنترل‌های دسترسی دیگر منحصراً به افراد مرتبط نیستند. شما با استفاده از حساب‌هایی وارد می‌شوید که توسط Kubernetes مدیریت نمی‌شوند اما برای سیستم شناخته شده‌اند. حساب‌های سرویس، حساب‌هایی هستند که در Kubernetes ایجاد و مدیریت می‌شوند. آنها دسترسی به موجودیت های ایجاد شده در Kubernetes را تنظیم می کنند، به عنوان مثال ارتباط از یک pod به دیگری. دو سوال باید به وضوح در مفهوم امنیتی تنظیم شود:
- افرادی که با یک خوشه Kubernetes کار می کنند چه کاری مجاز هستند؟ ] هنگام استفاده از Kubernetes، لازم است از قبل یک مفهوم امنیتی ایجاد کنید: RBAC برای پیکربندی حقوق دسترسی دقیق برای منابع Kubernetes در سطح کلاستر یا در فضای نام استفاده می‌شود.
اندازه‌گیری 4: همیشه سیاست‌ها را بررسی کنید
منطقی است. برای استفاده از Open Policy Agent (OPA). OPA یک موتور منبع باز و قابل اجرا جهانی است که با استفاده از آن اجرای متن آگاه دستورالعمل های تعریف شده در کل خوشه قابل کنترل است. OPA کمک می کند تا اطمینان حاصل شود که دستورالعمل های داخلی رعایت می شوند. علاوه بر این، استقرار میکروسرویس‌های فردی باید در یک محیط مرحله آزمایش شود. در مورد تغییرات کد، توصیه می شود قانون دو نفر را بررسی کنید.
اندازه گیری 5: به ثبات سرور و توزیع منابع توجه کنید
یک خوشه Kuberntes تعداد زیادی کانتینر را اداره می کند، بنابراین منبع الزامات و محدودیت‌های کانتینرهای جداگانه دقیقاً تعریف شده است . این به Kubernetes کمک می کند تا pods را دقیقاً مدیریت کند. این نرم افزار به گونه ای طراحی شده است که از تمام منابع به خوبی استفاده کند. در سیستم هایی که با سهمیه منابع محدود نمی شوند، این خطر وجود دارد که پادها یا کانتینرها مقادیر زیادی از CPU و حافظه را برای برنامه های خاص مصرف کنند. در بدترین حالت، یک کشتن خارج از حافظه ممکن است رخ دهد – یک غلاف یا کانتینر تمام منابع موجود را در انحصار خود در می آورد و سایر غلاف ها یا کانتینرها تحت تأثیر قرار می گیرند. تنظیم شده در برنامه های کانتینری – اسکن های امنیتی منظم یک معیار معقول برای همه برنامه های کامپیوتری است . حتی در کلاسترهای کانتینر، نقاط ضعف مکرراً در نرم افزار مورد استفاده یافت می شود و مورد سوء استفاده قرار می گیرد. توصیه می شود حداقل یک بار در ماه سیستم های خود را از نظر نرم افزار قدیمی، شکاف های امنیتی شناخته شده یا پیکربندی های ناایمن بررسی کنید. به این ترتیب، همه افراد درگیر می توانند یک دید کلی داشته باشند و سیستم ها ایمن شوند. در Adacor ما همیشه مراقب به‌روزرسانی‌ها برای مشتریان خود هستیم.
برای مثال، بندر رجیستری کانتینر مبتنی بر ابر، حاوی یک اسکنر آسیب‌پذیری است که توجه را به شکاف‌های احتمالی جلب می‌کند. تصاویر کانتینر را می توان در فواصل زمانی برای مشکلات امنیتی بررسی کرد و در صورت حیاتی بودن، برای دانلودهای بیشتر مسدود کرد. به محض آپدیت و ایمن شدن تصویر، دوباره منتشر می شود. این قابلیت‌ها به توسعه‌دهندگان و مدیران کمک می‌کنند تا محیط‌های خود را به طور مؤثر ایمن کنند. شرکت ها می توانند با ایجاد یک مفهوم امنیتی از قبل از خود در برابر حملات محافظت کنند . ملاحظات اولیه باید شامل این باشد که آیا تهیه کانتینرهایی با حقوق ریشه ضروری است یا تا آنجا که ممکن است می‌توانید بدون آنها کار کنید. ارزیابی ریسک می تواند بسته به کاربرد متفاوت باشد و بر سرعت و انعطاف پذیری تأثیر بگذارد. زیرا ماشین های مجازی نسبت به خوشه های کانتینری "سبک بافته" طولانی تر بوت می شوند و منابع بیشتری مصرف می کنند. یک الزام مطلق برای توسعه دهندگان و مدیران: یادداشت های وصله را با دقت بخوانید و حقوق دسترسی دقیق را برای همه منابع Kubernetes در سطوح مختلف پیکربندی کنید. برای اینکه سیستم اضافه بار تولید نکند، منابع مورد نیاز و محدودیت ها باید از قبل تعریف شوند. مانند هر سیستم فناوری اطلاعات دیگری، اسکن‌های امنیتی منظم بخشی از مفهوم امنیت جامع است.
می‌توانید مقالات هیجان‌انگیز بیشتری درباره Kubernetes را در اینجا بخوانید:
. امنیت
