ممنظور از مشاهده‌پذیری و امنیت کوبرنتیز یا Kubernetes چیست؟ می توان گفت یک هاست ایمن می تواند پایه محکمی برای ساخت یک کلاستر کوبرنیز ایمن می باشد. وقتی‌که به یک هاست فکر می‌کنیم، وارد حوزه‌ی بارهای کاری می‌شویم که کلاستر Kubernetes را تشکیل می‌دهند. در این قسمت به تکنیک‌هایی خواهیم پرداخت که از یک وضعیت امنیتی قدرتمند برای Host اطمینان حاصل کنند.
انتخاب سیستم عامل
بسیاری از سازمان‌ها در کل زیرساخت خود، روی یک سیستم عامل واحد استانداردسازی می‌کنند که در این صورت انتخاب از قبل انجام شده است. اما اگر انعطاف برای انتخاب سیستم عامل وجود داشته باشد، بد نیست که یک توزیع Linux مدرن و تغییرناپذیر مدنظر قرار گیرد که به‌طور خاص برای Containerها طراحی شده باشد. این توزیع‌ها دارای مزیت‌های زیر هستند:
- آن‌ها معمولاً دارای کرنل‌های جدیدتر هستند که شامل رفع آخرین آسیب‌پذیری‌ها، به‌علاوه‌ی پیاده‌سازی‌های به‌روز تکنولوژی‌های جدیدتر مثل eBPF می‌باشند که ابزار مانیتورینگ امنیتی و شبکه Kubernetes می‌توانند از آن بهره ببرند.
- آن‌ها به‌صورت تغییرناپذیر طراحی شده‌اند که مزایای بیشتری برای امنیت به همراه دارد. در این ساختار، تغییرناپذیری بدین معنا است که Root Filesystem قفل شده است و برنامه‌های کاربردی نمی‌توانند آن را تغییر دهند. برنامه‌های کاربردی را فقط می‌توان با استفاده از Containerها نصب نمود. این کار برنامه‌های کاربردی را از Root Filesystem جداسازی کرده و توانایی برنامه‌های کاربردی مخرب برای نقض امنیتی Host را به‌شدت کاهش می‌دهد.
- آن‌ها معمولاً شامل قابلیت به‌روزرسانی خودکار به نسخه‌های جدیدتر هستند و نسخه‌های Upstream برای انتشار سریع آماده می‌شوند تا به آسیب‌پذیری‌های امنیتی پاسخ داده شود.
راهکار Kubernetes چیست و چه مزایایی دارد
ویدیوهای بیشتر درباره ی Kubernetes
دو مثال محبوب از توزیع‌های Linux تغییرناپذیر که برای Containerها طراحی شده‌اند، عبارت‌اند از Flatcar Container Linux که در ابتدا مبتنی بر CoreOS Container Linux بود و Bottlerocket که در ابتدا توسط Amazon ساخته و نگهداری می‌شد.
بیشتر بخوانید: پلتفرم Kubernetes چیست و چه مزایایی دارد؟ – قسمت اول
فارغ از اینکه کدام سیستم عامل انتخاب شود، مانیتور کردن اعلانات امنیتی Upstream اقدام مناسبی است تا متوجه شویم که آسیب‌پذیری‌های امنیت جدید چه زمانی شناسایی و افشا شده‌اند و اطمینان حاصل کنیم که جهت رسیدگی به آسیب‌پذیری‌های امنیتی، فرایندهای لازم برای به‌روزرسانی کلاستر به یک نسخه‌ی جدیدتر وجود دارد. با توجه به ارزیابی‌های انجام شده از این آسیب‌پذیری‌ها، تصمیم گرفته خواهد شد که آیا کلاستر به نسخه‌ی جدید سیستم عامل به‌روزرسانی گردد یا خیر. وقتی‌که به انتخاب سیستم عامل فکر می‌کنیم، باید Libraryهای مشترک از سیستم عامل هاست را نیز مدنظر قرار دهیم و تأثیر آن‌ها روی Containerهایی که روی Host پیاده‌سازی می‌شوند را درک کنیم.
یکی دیگر از بهترین راهکارهای امنیتی این است که اطمینان حاصل کنیم توسعه‌دهندگان برنامه کاربردی به نسخه‌ی به‌خصوصی از سیستم عامل یا Kernel متکی نباشند، زیرا در این صورت نمی‌توانیم سیستم عامل Host را طبق نیاز خود به‌روزرسانی نماییم.
فرایندهای غیرضروری
هر فرایند Host در حال اجرا، می‌تواند یک مسیر حمله برای هکرها باشد. از نظر امنیتی، بهترین کار این است که هر فرایند غیرضروری که ممکن است به‌طور پیش‌فرض اجرا شود، حذف گردد. اگر فرایندی برای اجرای موفق کوبرنتیز، مدیریت Host یا امنیت Host موردنیاز نیست، بهتر است فرایند اجرا نشود. نحوه‌ی غیرفعال کردن فرایند بستگی به تنظیم خواهد داشت مثلاً تغییر پیکربندی systemd یا حذف اسکریپت ابتدایی از /etc/init.d/.
اگر از یک توزیع Linux تغییرناپذیر استفاده شود که برای Containerها بهینه‌سازی شده باشد، فرایندهای غیرضروری به‌خودی‌خود حذف می‌شوند و برنامه‌های کاربردی یا فرایندهای بیشتر را فقط می‌تواند به‌صورت Container اجرا کرد.
فایروال مبتنی بر Host
برای ایمن‌سازی بیشتر سرورها یا VMهایی که Kubernetes روی آن‌ها Host شده است، می‌توان خود Host را با قواعد فایروال Local پیکربندی کرد تا مشخص شود که کدام پورت‌ها و محدوده‌های آدرس IP اجازه‌ی تعامل با Host را دارند.
بسته به سیستم عامل، می‌توان این کار را با ابزار ادمین Linux قدیمی مثل قواعد iptables یا پیکربندی Firewalld انجام داد. حتماً باید اطمینان حاصل گردد که این قواعد هم با Kubernetes Control Plane و هم با افزونه‌های شبکه Kubernetes که قصد استفاده از آن را داریم تطبیق‌پذیر باشند تا Kubernetes Control Plane یا Control Plane شبکه Pod را مسدود نکنند. تنظیم درست این قواعد و به‌روز نگه داشتن آن‌ها در طول زمان می‌تواند یک فرایند زمان‌بر باشد. به‌علاوه، اگر از یک توزیع Linux تغییرناپذیر استفاده گردد، شاید نتوان به‌راحتی و به‌طور مستقیم از این قواعد استفاده کرد.
خوشبختانه، برخی از افزونه‌های شبکه Kubernetes می‌توانند به حل این مشکل کمک کنند. مثلاً چندین افزونه شبکه Kubernetes مثل Weave Net، Kube-router و Calico دارای توانایی اعمال پالیسی‌های شبکه هستند. این افزونه‌ها باید بررسی شوند و افزونه‌ای انتخاب گردد که از اعمال پالیسی‌های شبکه به خود Hostها و نه فقط Podهای Kubernetes را نیز پشتیبانی کند. این کار باعث می‌شود که ایمن‌سازی Hostها در کلاستر بسیار ساده‌تر گردد و تا حد زیادی نسبت به سیستم عامل مستقل است و با توزیع‌های Linux تغییرناپذیر نیز کار می‌کند.
همیشه باید در مورد جدیدترین راهکارها تحقیق کرد
درحالی‌که آسیب‌پذیری‌ها یا مسیرهای حمله‌ی جدید توسط جامعه‌ی پژوهش امنیتی شناسایی می‌شوند، بهترین راهکارهای امنیتی نیز در طول زمان تکامل پیدا می‌کنند. بسیاری از این موارد به‌خوبی به‌صورت آنلاین ثبت شده و به‌طور رایگان قابل‌دسترسی هستند.
مثلاً مرکز امنیت اینترنت راهنمایی‌هایی را به‌صورت فایل‌های PDF فراهم کرده است که به کاربران کمک می‌کند پیکربندی‌های لازم را جهت ایمن‌سازی اکثر سیستم عامل‌ها انجام دهند. این فایل‌ها که به نام Benchmarkهای CIS شناخته می‌شوند، منبعی عالی هستند برای اطمینان حاصل کردن از اینکه
تمام اقدامات ضروری برای ایمن‌سازی سیستم عامل Host انجام می‌گردد. باید توجه داشت که Benchmarkهایی مخصوص Kubernetes وجود دارد که در ادامه به آن‌ها خواهیم پرداخت.
تقویت کلاستر
Kubernetes به‌طور پیش‌فرض ایمن نیست. پس علاوه بر تقویت Hostهایی که یک کلاستر را می‌سازند، مهم است که خود کلاستر نیز تقویت گردد. برای انجام این کار می‌توان اقدامات روبه‌رو را انجام داد: مدیریت پیکربندی و اجزای Kubernetes، احراز هویت و کنترل دسترسی مبتنی بر نقش RBAC و به‌روزرسانی کلاستر به آخرین نسخه‌های Kubernetes برای اطمینان حاصل کردن از اینکه آخرین اصلاحات برای آسیب‌پذیری‌ها در کلاستر انجام شده است.
ایمن‌سازی Kubernetes Datastore
Kubernetes از etcd به‌عنوان Datastore اصلی خود استفاده می‌کند. کل پیکربندی کلاستر و وضعیت مطلوب در اینجا ذخیره می‌شود. دسترسی داشت به etcd Datastore درواقع مساوی داشتن لاگین Root روی تمام Nodeها است. اگر یک عامل مخرب به etcd Datastore دسترسی پیدا کند، تقریباً هر اقدام امنیتی دیگری که در کلاستر قرار گیرد بی‌اثر خواهد شد. زیرا آن عامل کنترل کاملی روی کلاستر خواهد داشت که شامل توانایی اجرای Containerهای دلخواه با سطح دسترسی بالا روی هر Nodeی است.
راه اصلی برای ایمن‌سازی etcd استفاده از ویژگی‌های امنیتی است که توسط خود etcd فراهم می‌گردد. این ویژگی‌ها مبتنی بر x509 Public Key Infrastructure یا PKI هستند و از ترکیبی از Keyها و Certificateها استفاده می‌کنند. آن‌ها اطمینان حاصل می‌کنند که تمام داده‌های در حال حرکت با TLS رمزگذاری گردند و تمام دسترسی با اطلاعات اعتباری قدرتمند محدود شود. بهترین کار این است که etcd با مجموعه‌ای از اطلاعات اعتباری یعنی Pairها و Certificateهای کلیدی برای ارتباطات Peer بین Instanceهای etcd مختلف و مجموعه‌ی دیگری از اطلاعات اعتباری برای ارتباطات Client از Kubernetes API پیکربندی شود. به‌عنوان بخشی از این پیکربندی، etcd باید با جزئیاتی از Certificate Authority یا CA پیکربندی شود تا اطلاعات اعتباری Client ایجاد گردد.
وقتی‌که etcd به‌درستی پیکربندی شود، فقط Clientها با Certificateهای معتبر می‌توانند به آن دسترسی پیدا کنند. سپس سرور Kubernetes API باید با Client Certificate، Key و Certificate Authority پیکربندی شود تا بتواند به etcd دسترسی پیدا کند.
همچنین می‌توان از قواعد فایروال در سطح شبکه استفاده کرد تا دسترسی به etcd محدود گردد و فقط بتوان از Nodeهای کنترل Kubernetes که Kubernetes API server را Host می‌کند به آن دسترسی پیدا کرد. بسته به محیط، می‌توان از یک فایروال قدیمی، فایروال کلود مجازی یا قواعد روی Hostهای etcd مثلاً پیاده‌سازی یک پالیسی شبکه که از حفاظت Host Endpoint پشتیبانی کند نیز استفاده کرد تا ترافیک مسدود شود. بهترین کار این است که این روش علاوه بر ویژگی امنیتی خود etcd، به‌عنوان بخشی از استراتژی دفاع عمیق مورد استفاده قرار بگیرد، زیرا محدود کردن دسترسی با قواعد فایروال پاسخگوی نیاز امنیتی برای رمزگذاری داده‌های حساس Kubernetes در زمان انتقال نیست.
علاوه بر ایمن‌سازی دسترسی etcd برای Kubernetes، پیشنهاد می‌شود که از Kubernetes etcd Datastore برای چیزی به غیر از Kubernetes استفاده نگردد. به‌عبارت‌دیگر، داده‌هایی که مربوط به Kubernetes نیستند، نباید درون Datastore ذخیره شوند و اجزای دیگر نیز نباید به کلاستر etcd دسترسی داشته باشند. اگر برنامه‌های کاربردی یا زیرساخت در کلاستر یا خارج از کلاستر اجرا شوند که از etcd به‌عنوان یک Datastore استفاده کنند، بهترین راهکار این است که یک کلاستر etcd مجزا برای این کار تنظیم گردد. موردی که می‌تواند استثنا باشد، صورتی است که برنامه کاربردی یا زیرساخت دارای سطح دسترسی بالایی باشد و نقض امنیتی Datastore آن موجب نقض امنیتی کاملی در Kubernetes گردد. همچنین بسیار مهم است که Backupهایی از etcd نگهداری شود و Backupها ایمن‌سازی گردند تا بتوان پس از خرابی‌هایی مثل یک ارتقای ناموفق یا حادثه‌ای امنیتی بازیابی انجام داد.
