Hardening عملی Kubernetes: راهنمای عملی

Kubernetes به طور پیش‌فرض با انعطاف‌پذیری و نه امنیت به بازار می‌آید. هر پورت باز، نقش RBAC مجاز، و پادی نامحدود یک دعوت است. تقویت امنیت یک خوشه به معنای بستن سیستماتیک این شکاف‌ها بدون شکستن بارهایی است که به آن‌ها وابسته‌اند. این یک تمرین چک‌لیست نیست—این یک انضباط مستمر است که لایه‌های هویت، شبکه، بار کاری، و زنجیره تأمین را شامل می‌شود.

ابتدا صفحه کنترل را قفل کنید

سرور API واحدترین هدف ارزشمند در هر خوشه است. با غیرفعال کردن احراز هویت ناشناس شروع کنید و روش‌های احراز هویت قوی را اعمال کنید—ادغام OIDC با ارائه‌دهنده هویت شما بر استاتیک توکن‌ها یا گواهی‌های مشتری که هرگز منقضی نمی‌شوند ترجیح دارد. دسترسی به فروشگاه داده etcd را محدود کنید، زیرا هر راز و شی پیکربندی را به‌صورت متن ساده نگه می‌دارد مگر اینکه رمزگذاری در حالت استراحت فعال باشد. رمزگذاری را برای راز‌ها با استفاده از ارائه‌دهنده KMS فعال کنید نه اینکه بر کدگذاری base64 تکیه کنید، که حفاظت واقعی صفر ارائه می‌دهد. ثبت‌کردن حسابرسی باید از روز اول روشن باشد؛ بدون آن، هیچ مسیر بررسی قانونی ندارید وقتی چیزی اشتباه می‌شود.

RBAC: کمترین امتیاز، نه راحتی

رایج‌ترین پیکربندی‌اشتباه در خوشه‌های تولید، اتصالات RBAC بیش از حد گسترده است—cluster-admin که به حساب‌های سرویس داده می‌شود که تنها نیاز به خواندن پاد‌ها در یک namespace دارند. نقش‌ها را بر اساس تابع شغلی واقعی بسازید و آن‌ها را جایی که ممکن است به namespace‌ها محدود کنید. از فعل‌های وحش‌صورت و منابع در تعریف Role و ClusterRole اجتناب کنید. به طور منظم اتصالات را با ابزارهایی مانند kubectl auth can-i --list یا rbac-lookup حسابرسی کنید تا رشد امتیاز را بگیرید. حساب‌های سرویس همان دقت را مستحق‌اند که کاربران انسانی—خودکار بستن توکن حساب سرویس برای پاد‌هایی که به دسترسی API نیاز ندارند.

امنیت پاد: فرض کنید سازشی خورده است

Pod Security Admission (که PodSecurityPolicy منسوخ‌شده را جایگزین کرد) به شما اجازه می‌دهد پروفایل‌های پایه یا محدود را در سطح namespace اعمال کنید. حداقل، کانتینرهای امتیاز‌دار، اشتراک namespace میزبان، و افزایش امتیاز را غیرمجاز اعلام کنید. runAsNonRoot: true را تنظیم کنید و تمام قابلیت‌های Linux را به طور پیش‌فرض کاهش دهید، تنها آنچه را به صراحت مورد نیاز است برگردانید. سیستم فایل ریشه فقط‌خواندنی از نویسندگان جلوگیری می‌کند که دودویی‌های بدخواه را در کانتینری در حال اجرا نویسند. این کنترل‌ها اهمیت دارند زیرا یک فرار کانتینر یا آسیب‌پذیری برنامه‌ای استفاده‌شده نباید به سازشی گره کامل ترجمه شود.

سیاست‌های شبکه اختیاری نیستند

به طور پیش‌فرض، هر پاد در یک خوشه Kubernetes می‌تواند با هر پاد دیگری صحبت کند. آن مدل شبکه صاف یک رویای حرکت جانبی برای مهاجمان است. منابع NetworkPolicy را اعمال کنید تا ingress و egress پیش‌فرض-انکار را اعمال کنید، سپس به صراحت تنها جریان‌های ترافیکی را مجاز کنید که برنامه‌های شما نیاز دارند. این نیاز به یک افزونه CNI دارد که واقعاً از اعمال NetworkPolicy پشتیبانی کند—Calico، Cilium، و دیگران این نقش را پر می‌کنند زیرا مدل شبکه Kubernetes پایه‌ای خود چیزی را اعمال نمی‌کند. تقسیم namespace‌ها بر اساس مرز اعتماد و لایه‌بندی سیاست‌ها در بالا به شما دفاع واقعی در عمق می‌دهد.

تمامیت تصویر و زنجیره تأمین

تقویت امنیت در پیکربندی زمان‌اجرا متوقف نمی‌شود—با آنچه شما استقرار می‌دهید شروع می‌شود. تصاویر کانتینر را برای آسیب‌پذیری‌های شناخته‌شده قبل از اینکه به رجیستری شما برسند اسکن کنید، و اعمال کنید که تنها تصاویر امضاشده و تایید‌شده می‌توانند با استفاده از کنترل‌کننده‌های ورودی مانند Kyverno یا OPA Gatekeeper در خوشه شما اجرا شوند. برچسب‌های تصویر را به digest بندی کنید نه برچسب‌های قابل تغییر مثل latest، که می‌توانند به خاموشی تحت تغییر شوند. محدود کنید کدام رجیستری‌ها پاد‌ها می‌توانند از آن‌ها بکشند، بسته‌کردن یک مسیر رایج برای حملات زنجیره تأمین جایی که تصاویر سازشی یا typosquatted در تولید لغزند.

مدیریت اسرار فراتر از پیش‌فرض‌های Kubernetes

اسرار بومی Kubernetes بهتر از هیچ‌چیز نیست، اما آن‌ها یک راه‌حل واقعی مدیریت اسرار نیستند. ادغام یک مدیر اسرار خارجی را در نظر بگیرید—Vault، AWS Secrets Manager، یا مشابه—و اسرار را در زمان اجرا تزریق کنید نه ذخیره‌شان به عنوان اشیاء خوشه. اگر باید از اسرار بومی استفاده کنید، اطمینان دهید که رمزگذاری etcd فعال است و RBAC به‌تنگی دسترسی خواندن را محدود می‌کند، زیرا هر پاد یا کاربری با اجازه get بر روی اسرار در یک namespace می‌تواند اعتبارات را exfiltrate کند.

تایید مستمر، نه تنظیم یک‌بار

پیکربندی‌های تقویت امنیت در طول زمان تغییر می‌کنند زیرا بارهای کاری جدید استقرار می‌یابند و اولویت‌ها به سمت سرعت بر امنیت تغییر می‌کند. ابزارهایی مانند kube-bench انطباق را بر اساس CIS Kubernetes Benchmark بررسی می‌کنند، در حالی که kube-hunter می‌تواند reconnaissance مهاجم را در برابر خوشه شما شبیه‌سازی کند. این بررسی‌ها را در خط‌لوله CI/CD بچسبانید تا پیکربندی‌های اشتباه قبل از رسیدن به تولید به جای طول یک تماس پاسخ‌دهندگی بگیرند.

تقویت امنیت Kubernetes کمتر درباره یک کنترل نقره‌فام است و بیشتر درباره لایه‌بندی دفاع‌ها در سراسر هویت، شبکه، بار کاری، و زنجیره تأمین—به طوری که یک شکست در یک لایه به سازشی کامل cascade نشود. برای اطلاعات بیشتر درباره الگوهای امنیت زیرساخت ابر و ابزارهای دفاعی، بخش‌های مرتبط را در پلتفرم DEFENSE_GRID استودیوی Korra کاوش کنید.