اجرای استانداردهای امنیتی pod

این صفحه مروری بر بهترین شیوه‌ها در مورد اجرای استانداردهای امنیتی پاد ارائه می‌دهد.

استفاده از کنترل‌کننده پذیرش امنیتی داخلی pod

کنترل‌کننده‌ی پذیرش امنیت پاد Pod Security Admission Controller قصد دارد جایگزین سیاست‌های امنیتی منسوخ‌شده‌ی پاد (PodSecurityPolicies) شود.

پیکربندی تمام Namespace های کلاستر

namespace یی که فاقد هرگونه پیکربندی هستند، باید به عنوان شکاف‌های قابل توجه در مدل امنیتی کلاستر شما در نظر گرفته شوند. توصیه می‌کنیم برای تجزیه و تحلیل انواع Workloads موجود در هر namespace، وقت بگذارید و با مراجعه به استانداردهای امنیتی پاد، سطح مناسبی را برای هر یک از آنها تعیین کنید. فضاهای نام بدون برچسب فقط باید نشان دهند که هنوز ارزیابی نشده‌اند.

در سناریویی که همه Workloads در همه namespace ها الزامات امنیتی یکسانی دارند، ما یک مثال ارائه می‌دهیم که نحوه اعمال برچسب‌های PodSecurity را به صورت انبوه نشان می‌دهد.

اصل حداقل امتیاز را بپذیرید

در یک دنیای ایده‌آل، هر پاد در هر فضای نامی الزامات سیاست محدود را برآورده می‌کند. با این حال، این امر نه ممکن است و نه عملی، زیرا برخی از Workloads به دلایل موجه به امتیازات بالاتری نیاز دارند.

• namespace هایی که به Workloads «ممتاز» اجازه می‌دهند، باید کنترل‌های دسترسی مناسبی را ایجاد و اجرا کنند.
• برای Workloads که در آن namespace های مجاز اجرا می‌شوند، مستندات مربوط به الزامات امنیتی منحصر به فرد آنها را نگهداری کنید. در صورت امکان، در نظر بگیرید که چگونه می‌توان این الزامات را بیشتر محدود کرد.

اتخاذ یک استراتژی چند حالته

حالت‌های audit و warn کنترل‌کننده پذیرش استانداردهای امنیتی پاد ، جمع‌آوری بینش‌های امنیتی مهم در مورد پادهای شما را بدون ایجاد اختلال در حجم کار موجود، آسان می‌کند.

فعال کردن این حالت‌ها برای همه namespace ها، و تنظیم آنها روی سطح و نسخه مورد نظر شما که در نهایت می‌خواهید enforce کنید، یک تمرین خوب است. هشدارها و حاشیه‌نویسی‌های حسابرسی ایجاد شده در این مرحله می‌توانند شما را به سمت آن وضعیت هدایت کنند. اگر انتظار دارید نویسندگان بار کاری تغییراتی را برای مطابقت با سطح مورد نظر ایجاد کنند، حالت warn را فعال کنید. اگر انتظار دارید از گزارش‌های حسابرسی برای نظارت/هدایت تغییرات برای مطابقت با سطح مورد نظر استفاده کنید، حالت audit را فعال کنید.

وقتی حالت enforce را روی مقدار دلخواه خود تنظیم کرده‌اید، این حالت‌ها همچنان می‌توانند به چند روش مختلف مفید باشند:

• با تنظیم warn در همان سطح enforce، کلاینت‌ها هنگام تلاش برای ایجاد Podها (یا منابعی که قالب‌های Pod دارند) که اعتبارسنجی را پشت سر نمی‌گذارند، هشدارهایی دریافت می‌کنند. این به آنها کمک می‌کند تا آن منابع را برای مطابقت به‌روزرسانی کنند.
• در namespaceهایی که enforce را به یک نسخه غیرجدید خاص پین می‌کنند، تنظیم حالت‌های audit و warn در همان سطح enforce، اما به نسخه latest، امکان مشاهده تنظیماتی را فراهم می‌کند که در نسخه‌های قبلی مجاز بودند اما طبق بهترین شیوه‌های فعلی مجاز نیستند.

جایگزین‌های شخص ثالث

گزینه‌های دیگری برای اجرای پروفایل‌های امنیتی در اکوسیستم کوبرنتیز در حال توسعه هستند:

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

تصمیم برای استفاده از یک راهکار داخلی (مثلاً کنترل‌کننده پذیرش PodSecurity) در مقابل یک ابزار شخص ثالث، کاملاً به شرایط شما بستگی دارد. هنگام ارزیابی هر راهکاری، اعتماد به زنجیره تأمین شما بسیار مهم است. در نهایت، استفاده از هر یک از رویکردهای فوق‌الذکر بهتر از انجام ندادن هیچ کاری خواهد بود.