امنیت کوبرنتیس

برای برقراری امنیت کوبرنتیس باید در لایه های مختلف و توسط تیم های متفاوت اقداماتی انجام شود، در این مقاله به عنوان مدیر کلاستر کوبرنتیس باید اقداماتی انجام شود تا آسیب پذیری کلاستر و اپلیکیشن های در حال اجرا بر روی کلاستر را به حداقل رساند. به عبارت دیگر با انجام مجموعه ای از اقدامات نباید اجازه راه اندازی اپلیکیشن هایی که می توانند امنیت کلاستر را به خطر بیاندازند را داد. برخی از اقدامات امنیتی باید در زمان ساخت ایمیج های اپلیکیشن انجام شود که باید توسط تیم DevOps و در پایپ لاین CI/CD مورد توجه قرار بگیرند. در این مقاله تمرکز بر روی اقداماتی است که توسط مدیر کلاستر کوبرنتیس در لایه سرور و کلاستر کوبرنتیس انجام می شود. لازم به ذکر است تمام موارد ذکر شده در این مقاله از کتاب هایی که نام آن ها در بخش منابع آمده، جمع آوری شده است. همچنین فرض بر آن است که خواننده این مقاله با مفاهیم کوبرنتیس آشنایی کامل داشته باشد.

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

در مرحله اول برای راه اندازی کلاستر کوبرنتیس باید از سرور هایی به عنوان وورکر یا مستر استفاده کرد. انتخاب سیستم عامل برای این سرور ها اولین اقدام برای برقراری امنیت کلاستر کوبرنتیس است. در صورتی که سازمان تاکیدی بر استفاده از سیستم عامل خاصی ندارد می توان از توزیع های لینوکسی غیرقابل تغییر استفاده کرد. مزیت استفاده از این سیستم عامل ها lock بودن root filesystem آن است که باعث می شود قابلیت تغییر توسط اپلیکیشن ها را نداشته باشد. قابلیت به روز رسانی خودکار این نوع سیستم عامل نیز کمک بزرگی در کاهش ریسک آسیب پذیری های عمومی و شناخته شده می کند. در صورتی که امکان استفاده از قابلیت به روزرسانی خودکار سیستم عامل وجود ندارد باید به صورت دستی سیستم عامل به آخرین نسخه به روز رسانی شود. لیستی از سیستم عامل های غیرقابل تغییر و معروف در زیر آمده است:

• Flatcar Container Linux
• Bottlerocket
• RancherOS
• Red Hat Atomic

سرور هایی که به عنوان وورکر یا مستر در کلاستر از آن ها استفاده می شود نیازی به اجرای فرآیند های خاصی نظیر kubelet یا container engine دارند. سایر فرآیند های نامرتبط با محیط کوبرنتیس به عنوان فرآیند های غیر ضروری شناخته می شوند و باید از روی این سرور ها حذف شوند. در صورتی که از سیستم عامل های غیرقابل تغییر استفاده شود، این سیستم عامل ها برای استفاده در محیط های کانتینری بهینه سازی شده اند و فرآیند های غیرضروری از قبل بر روی این سرور ها وجود نخواهد داشت.

با استفاده از دیواره آتش محلی تنها پورت های ضروری بر روی سرور قابل دسترس باشند، این پورت های ضروری برای ترافیک های وروردی خاص با آدرس های IP مشخص باید در دسترس باشند. در جدول زیر پورت هایی که باید بر روی هر سرور (با توجه به نقش آن ها در کلاستر کوبرنتیس) باز باشند، مشخص شده است.

یکی از اجزاء مهم سرور هایی که در کلاستر کوبرنتیس استفاده می شوند container engine ها هستند. برخی از container engine ها را می توان به صورت unprivileged راه اندازی کرد به این صورت که از یوزر روت برای اجرای daemon آن استفاده نشود. به این روش از راه اندازی، rootless container engine گفته می شود. با وجود اینکه این رویکرد، سطح خوبی از امنیت را فراهم می کند اما بسیاری از container engine های موجود این ویژگی را به صورت پایدار راهی بازار نکرده اند و این ویژگی در مرحله آزمایشی قرار دارد. اما لازم است تا در صورت راهی شدن یک نسخه پایدار از این ویژگی که با محیط کوبرنتیس سازگار باشد، مدیر کلاستر کوبرنتیس برای ارتقا امنیت از آن استفاده کند.

در نهایت باید در سطح سیستم عامل لاگ های تولید شده برای SSH، OS audit و کرنل را جمع آوری کرد و با استفاده از ابزار های مصور سازی و تحلیل لاگ، هشدارهایی برای مخاطرات امنیتی احتمالی در نظر گرفت.

امن کردن کلاستر کوبرنتیس

کاربران از طریق kubernetes API server با کلاستر کوبرنتیس ارتباط برقرار می کنند. پس از ارسال درخواست به API server اطلاعات موجود در درخواست در یک پایگاه داده توزیع شده کلید-مقدار با نام etcd ذخیره می شود. ملاحظات امنیتی در این بخش از عملکرد کلاستر کوبرنتیس متمرکز می شود که در ادامه به بررسی آن پرداخته می شود.

امن کردن kubernetes API Server

از آنجایی که تمامی ارتباطات بین اجزاء کنترلی کوبرنتیس و API server آن مبتنی بر TLS است، توصیه شده است که در بازه های زمانی کوتاه گواهی نامه های ارتباطی را تغییر دهیم این امر با اصطلاح Rotating credentials شناخته شده است.

برای کاربرانی که قرار است با کلاستر کوبرنتیس تعامل داشته باشند، بهتر است حساب کاربری مجزا در نظر گرفت سپس با استفاده از مکانیسم کنترل سطح دسترسی مبتنی بر نقش یا RBAC دسترسی لازم به کاربران داده شود. این دسترسی باید متناسب با تعامل کاربر با کلاستر باشد و دسترسی بیشتری به کاربر اعطا نشود. به طور کلی کوبرنتیس قابلیت احراز هویت محدودی برای کاربران در نظر گرفته است اما این امکان وجود دارد که با یک ابزار مدیریت کاربران مثل LDAP یا Keystone یکپارچه شود. در صورت یکپارچه شدن با یک ابزار مدیریت کاربران امکان تغییر گواهینامه کاربران (برای تعامل با API server کوبرنتیس) به صورت خودکار و دوره ای فراهم می شود، این فرآیند باید به نحوی باشد که کاربر از تغییر گواهینامه با خبر نشود و ارتباط آن با کلاستر دچار اختلال نشود. یکی از مزایای استفاده از حساب کاربری مجزا امکان فعال کردن لاگ audit کوبرنتیس و ذخیره سازی آن ها در یک زیرساخت ذخیره لاگ است. با تحلیل کردن و ایجاد داشبورد و آلارم های مناسب می توان مخاطرات امنیتی را تشخیص داد. لاگ audit در سطوح مختلف و برای منابع مختلف کلاستر کوبرنتیس از طریق تعریف کردن policy امکان پذیر است. در هنگام تعریف policy می توان مشخص کرد که برای رویداد های چه منابعی و با چه سطح از جزئیات لاگ تولید شود. بنابراین فعال کردن لاگ audit در کوبرنتیس کاملا تنظیم پذیر است. علاوه بر لاگ audit باید لاگ های مربوط به CNI و DNS کوبرنتیس نیز جمع آوری و تحلیل شود.

هر نسخه کوبرنتیس شامل منابعی با نسخه های آلفا و بتا هست. چون این نسخه ها تحت توسعه هستند امکان وجود باگ و آسیب پذیری امنیتی در آن ها بالا است. بنابراین بهتر است امکان استفاده از نسخه های آلفا و بتا را غیرفعال کرد. نسخه های آلفا معمولا (اما نه همیشه) غیرفعال هستند و توصیه می شود که در کلاستر های عملیاتی از آن ها استفاده نشود، اما استفاده در کلاستر های تستی بلامانع است. نسخه های بتا به طور پیش فرض فعال هستند و تا حد خوبی مکانیسم های امنیتی در آن ها تست شده است اما به علت فراگیر نبودن و استفاده کمتر از آن ها، پتانسیل بروز آسیب پذیری امنیتی در آن ها بالا است. این کار از طریق تنظیم API server کوبرنتیس انجام می شود. API Server کوبرنتیس می تواند بر روی دو پورت سرویس دهی کند، پورت پیش فرض 8080 که با فلگ insecure-bind-address قابل تنظیم است. در صورتی که API server از این پورت استفاده کند مراحل احراز هویت و کنترل سطح دسترسی توسط API server انجام نمی گیرد که از لحاظ امنیتی خطر بزرگی محسوب می شود، در نتیجه لازم است که API server از فلگ secure-port که بر روی پورت پیش فرض 6443 فعالیت می کند، استفاده کند تا از انجام احراز هویت و کنترل سطح دسترسی اطمینان حاصل شود.

در تنظیمات API server در صورتی که فلگ anonymous-auth فعال باشد، API server به کاربرانی که احراز هویت نشده باشند این امکان را می دهد که بتوانند به آن متصل شوند. از نسخه 1.6 به بعد کوبرنتیس این فلگ به صورت پیش فرض فعال هست که باید غیرفعال شود.

نکته آخر در تنظیمات API server استفاده از پلاگین های از پیش تعریف شده admission-control است که اطلاعات ارسال شده سمت کاربر را اعتبار سنجی می کند. البته امکان استفاده از admission-control های شخصی سازی شده با استفاده از webhook هم وجود دارد تا با استفاده از آن ها بتوان اعتبار سنجی درخواست های وارد شده را انجام داد و در صورت نیاز تغیراتی بر روی درخواست های وارد شده اعمال کرد. به علت گستردگی این مبحث سعی بر بررسی این موضوع در یک مقاله جداگانه داریم. اما در این مرحله بهتر است از پلاگین های از پیش تعریف شده API server برای تامین امنیت بهره برد. همچنین استفاده از ImagePolicyWebhook برای جلوگیری از پیاده سازی کانتینرهایی که ایمیج های آن ها دارای آسیب پذیری هست، نیز توصیه می شود.

امن کردن etcd

استفاده از x509 PKI و TLS در ETCD به صورتی که تنها کلاینت ها با گواهی نامه معتبر بتوانند با ETCD ارتباط برقرار کنند و هرگونه ارتباط بین کلاینت و سرور ETCD به صورت رمز شده باشد. رمز کردن اطلاعات ذخیره شده حساس در ETCD مانند اطلاعات سکرت های کوبرنتیس، دو روش برای رمز کردن اطلاعات ETCD وجود دارد. استفاده از تنظیمات محلی کوبرنتیس که مدیریت کلید ها به صورت محلی انجام می شود و روش دوم استفاده از یک سامانه خارجی مدیریت کلید یا KMS مانند HashiCorp’s Vault است.

امن کردن kubelet

احراز هویت کاربران ناشناس برای kubelet باید غیرفعال شود تا نتوان به kubelet های موجود بر روی هر سرور بدون احراز هویت متصل شد. این کار در فایل کانفیگ kubelet قابل انجام است. از طرف دیگر نوع سطح دسترسی kubelet یا KubeletAuthorizationMode باید بر روی webhook تنظیم شود و در هیچ یک از kubelet ها از نوع AlwaysAllow استفاده نشود.

در نسخه های قدیمی کوبرنتیس از cadvisor در kubelet برای جمع آوری اطلاعات مانیتورینگ استفاده می شد. برای جلوگیری از در دسترس قرار گرفتن بار کاری روی سرور های کوبرنتیس باید با استفاده از فلگ cadvisor-port این دسترسی غیرفعال شود. البته از نسخه 1.11 کوبرنتیس این تنظیمات به صورت پیش فرض وجود دارد.

با استفاده از پروفایل های seccomp می توان قابلیت system call های کانتینر ها را محدود کرد. همچنین می توان مشخص کرد که اجرای کدام یک از system call ها توسط کانتینر مجاز هستند، کدام یک غیر مجاز هستند و لاگ کدام یک از آن ها باید ایجاد شود. برای استفاده از یک پروفایل شخصی سازی شده، پروفایل را با فرمت JSON، در مسیر /var/lib/kubelet/seccomp/ قرار داده می شود.

برای هرکدام از پاد ها باید محدودیتی در تعداد شناسه فرآیندها یا PID ها تعریف کرد که با استفاده از آن تعداد فرآیند های در حال اجرا بر روی هر پاد را محدود کرد. این کار از طریق تنظیمات kubelet قابل انجام است.

سایر موارد امنیتی جهت امن کردن کلاستر کوبرنتیس

با گذشت زمان میزان آسیب پذیری های شناخته شده برای نسخه های قدیمی کوبرنتیس بیشتر می شود، بنابراین به طور بالقوه کلاستر های قدیمی تر در معرض خطر بیشتری هستند. پس باید برنامه ای برای به روز رسانی دوره ای کلاستر کوبرنتیس وجود داشته باشد و حتی المقدور کلاستر کوبرنتیس باید روی آخرین نسخه باشد.

به دلیل ساختار متفاوت شبکه کوبرنتیس استفاده از Network Policies برای محدود کردن ارتباط شبکه ای به/از پادهای در حال اجرای کاربران بسیار با اهمیت است تا از دسترسی های غیر مجاز تحت شبکه جلوگیری کرد. لازم به ذکر است که برای این منظور باید از CNI plugin هایی استفاده کرد که از NetworkPolicy API پشتیبانی کنند.

یکی از راه های تشخیص خطرات امنیتی بررسی لاگ در سطوح مختلف است، توصیه می شود در لایه های زیر جمع آوری و تحلیل لاگ صورت بگیرد تا در صورت بروز ناهنجاری بتوان آن ها را کشف کرد.

• در سطح اپلیکیشن
• در سطح کلاستر کوبرنتیس از طریق جمع آوری لاگ شبکه، audit و DNS
• در سطح کانتینر از طریق جمع آوری لاگ فرآیندها، syscalls، شبکه و filesystem

با ابزارهای مختلفی نظیر falco، ebpf، kprobes، ptrace و tracepoints می توان جمع آوری لاگ در لایه های ذکر شده در بالا را انجام داد.

برای اطمینان از امن بودن کلاستر کوبرنتیس می توان از بنچ مارک CIS (Center Internet Security) برای کلاستر کوبرنتیس استفاده کرد. همچنین ابزار های متن باز تست نفوذ مانند kube-hunter نیز وجود دارد. توصیه می شود از این ابزار ها برای سنجش امنیت کلاستر کوبرنتیس استفاده کرد.

اما در نهایت راهکاری وجود دارد تا سطح مسئولیت خود را در برابر تامین امنیت کلاستر کوبرنتس به صفر کاهش داد. استفاده از کلاستر های کوبرنتیس مدیریت شده مانند پلتفرم ابریمنت به جای راه اندازی کلاستر کوبرنتیس باعث می شود تا از مزایای انعطاف پذیری و در دسترس پذیری کوبرنتیس بهره برد و در عین حال نگران مخاطرات امنیتی هم نبود.

منابع

• Kubernetes Security: Operating Kubernetes Clusters and Applications Safely
• Kubernetes Security and Observability: A Holistic Approach to Securing and Troubleshooting Cloud Native Applications