ارزیابی امنیت Kubernetes

ارزیابی امنیت Kubernetes، یک خوشه را برای ضعف‌های امنیتی می‌سنجد: پیکربندی نادرست RBAC و ارتقای امتیاز، workloadهای ناامن و نبود کنترل admission، سیاست‌های شبکه‌ی باز، افشای secret و صفحه‌ی کنترل سخت‌نشده؛ در برابر CIS Kubernetes Benchmark، راهنمای NSA/CISA و OWASP Kubernetes Top 10، و هر یافته اثبات و رتبه‌بندی می‌شود.

در درجه‌ی اول CIS Kubernetes Benchmark برای سخت‌سازی پیکربندی، راهنمای سخت‌سازی NSA/CISA برای صفحه‌ی کنترل و workloadها، و OWASP Kubernetes Top 10 برای دسته‌های رایج ریسک. Pod Security Standards را نیز مبنای تنظیمات workload قرار می‌دهیم.

معمولاً یک حساب سرویس فقط‌خواندنی و محدود و kubeconfig آن، تا بتوانیم بدون تغییر چیزی فهرست‌برداری و بازبینی کنیم. برای تست فرضِ‌نفوذِ حرکت جانبی و فرار، یک pod پایگاه در خوشه بهترین حالت است. پیش از شروع، دامنه، namespaceهای درگیر و هر چیزی را که باید کنار گذاشته شود توافق می‌کنیم.

هر دو. در خوشه‌ی مدیریت‌شده، ارائه‌دهنده صفحه‌ی کنترل را در مدل مسئولیت مشترک سخت می‌کند، پس ما بر آنچه بر عهده‌ی شما می‌ماند تمرکز می‌کنیم: RBAC، workloadها، سیاست‌های شبکه، secretها و پیکربندی node؛ در خوشه‌ی خودگردان، API server و etcd و kubelet را هم مستقیم بازبینی می‌کنیم.

RBAC تعیین می‌کند چه هویتی مجاز است چه کنشی را روی چه منبعی انجام دهد. ارتقای امتیاز یعنی یک نقش یا binding بیش از حد باز — حساب سرویسی که می‌تواند pod بسازد، secret بخواند یا جای دیگران را بگیرد — به یک پایگاه کم‌دسترسی اجازه می‌دهد به cluster-admin برسد. اهمیتش از این‌جاست که یک pod به‌خطرافتاده را به تسلط بر کل خوشه تبدیل می‌کند و برای اسکنی که فقط تنظیمات را جدا از هم بررسی می‌کند نامرئی است.

از یک pod پایگاه بررسی می‌کنیم که آیا سیاست‌های شبکه واقعاً ترافیک pod-به-pod و namespace-به-namespace را محدود می‌کنند — Kubernetes به‌طور پیش‌فرض همه را مجاز می‌داند — و آیا سرویس‌های در دسترس، توکن‌های حساب سرویس یا نقطه‌ی metadata ابری به ما اجازه می‌دهند جلوتر برویم یا امتیاز بگیریم. نتیجه، دامنه‌ی واقعی اثرِ یک pod به‌خطرافتاده است.

بازبینی و نقشه‌برداری فقط‌خواندنی و ایمن است. آزمون‌های فعال — تلاش برای فرار و حرکت جانبی — از پیش توافق و با احتیاط اجرا می‌شوند؛ ترجیح ما یک خوشه‌ی staging است که آینه‌ی تولید باشد، و اگر ناچار روی تولید تست کنیم، محدودیت می‌گذاریم و یک نقطه‌ی تماس در سمت شما نگه می‌داریم تا اگر چیزی نادرست به نظر رسید فوراً متوقف شویم.

هر یافته یک امتیاز CVSS برای یک مبنای مشترک می‌گیرد که با اثر واقعی در خوشه‌ی شما تعدیل می‌شود: مهاجم به چه می‌رسد، چقدر آسان، و آیا به cluster-admin یا داده می‌انجامد. به همین دلیل دو مسئله با CVSS یکسان ممکن است اولویت متفاوت بگیرند.

بله. پس از رفع، یافته‌های گزارش‌شده را دوباره تست می‌کنیم تا مطمئن شویم هر رفع پابرجاست و شکاف تازه‌ای باز نکرده، و وضعیت آن‌ها را در گزارش به‌روز می‌کنیم.

به تعداد خوشه‌ها، namespaceها و workloadها و به این‌که چه بخشی از پشته بر عهده‌ی شماست بستگی دارد؛ یک ارزیابی معمول حدود دو تا چهار هفته طول می‌کشد. پس از دامنه‌گذاری برآورد دقیق می‌دهیم.