ابتدا Kubernetes Framework توسط Google ارئه و توسعه پیدا کرد و در نهایت به پلتفرم پیشرو برای تنظیم بدل شد که برای خودکارسازی پیاده‌سازی، توسعه و عملیات Containerهای برنامه‌های کاربردی در تمامی کلاسترهای Hostها بکار می‌رود. این پلتفرم در تمامی Vendorهای پلتفرم Cloud به عنوان ابزاری که جهت تنظیم، خودکارسازی و آمادگی برنامه‌های کاربردی و نیازهای مشخص کلاسترهای رایانش و سرویس‌ها بکار می‌رود. Kubernetes عامل توسعه Containerها هستند و این Containerها ماشین‌های مجازی کوچکی هستند که سیستم‌های عملیاتی خالص، برنامه‌های کاربردی خاص و تعدادی از Packageهای اجرا کننده آنها را راه‌اندازی می‌کنند. این Containerها معمولا سبک، تعامل‌پذیر، و قابل استفاده مجدد هستند و درصورت پیاده‌سازی مستقیم با ایزوله‌سازی و بخش‌بندی امنیت را فراهم می‌کنند.
Kubernetes Framework پیاده‌سازی سریع منابع را به روشی ساده و با معماری آماده که توسعه مداوم منابع را ممکن می‌سازد انجام می‌دهد. یک کلاسترهای کوبرنتیس اصولا از یک Kubernetes Master و Nodeها ساخته شده است. Kubernetes Master مجموعه‌ای از سه فرآیند است که در یکی از Nodeهای کلاستر انجام می‌شوند و به عنوان یک Node اصلی طراحی شده. این فرآیند ها شامل Kube-Apiserver ،Kube-Controller-Manager و Kube-Scheduler هستند. Object اصلی درون کلاستر Etcd است که تمامی حالت کلاستر، پیکربندی آن، ویژگی‌ها و وضعیت‌های Workloadهای درحال اجرا را ذخیره می‌نماید.
Nodeهای فرعی موجود در کلاستر دو فرآیند را طی می‌کنند. Kubelet که اساسا یک Node Agent دارای ارتباط با Node اصلی و Kube Proxy بوده و Network Proxy مورد استفاده اجزای کلاستر جهت برقراری ارتباط است. از دیگر اجزای کلاستر می‌توان CAdvisor که یک Open Source Resource Usage Collector یا Web Interface است و Kube-Nodes که ماشین‌های کارکننده در کلاستر هستند را نام برد.
Nodeها معمولا ماشین‌های مجازی یا فیزیکی هستند که برنامه‌های کاربردی را اجرا می‌کنند. معماری Kubernetes معمولا از چندین جداسازی که به عنوان Object معرفی شده‌اند تشکیل شده که جهت درک عملکرد کلاسترهای کوبرنتیس و البته سطح حمله آن بسیار مهم هستند. موارد زیر شامل Objectها می‌شوند:
- Pod: واحد پایه اجرای برنامه کاربردی Kubernetes، کوچک‌ترین و ساده‌ترین واحد در مدل Kubernetes که پیاده‌سازی یا ایجاد می‌شود. یک Pod بیانگر فرآیندهای درحال پردازش در کلاستر هستند.
- سرویس: یک راه انتزاعی برای نمایش برنامه کاربردی که بر مجموعه‌ای از Podها به عنوان یک سرویس شبکه اجرا می‌شود.
- Volume: تنها یک دایرکتوری بوده که ممکن است کمی داده در خود داشته باشد و در یک Pod برای Containerها قابل دسترس است.
- Namespace: برای استفاده در محیط‌های دارای کاربران زیاد در چندین تیم یا پروژه
راهکار Kubernetes چیست و چه مزایایی دارد
ویدیوهای بیشتر درباره Kubernetes
جداسازی‌های دیگری نیز برای مرجع‌های عملکرد در معماری Kubernetes وجود دارند مانندDeployment ،DaemonSet ،StatefulSet ، ReplicaSet و Job. این Objectها بطور ویژه برای فراهم کردن پیکربندی‌های خاص و موارد کاربردی درون کلاسترهای کوبرنتیس طراحی شده‌اند و برخی از این Objectها که بخاطر مسائل امنیتی ارزشمند هستند، نیازمند توجه ویژه می‌باشند. چنین Objectهایی ConfigMapها و Secretها هستند. حال به بررسی دلیل اهمیت این دو مورد می‌پردازیم تا کلاسترها را ایمن نگه‌داریم.
ConfigMapها: شامل مواردی مانند فایل‌های پیکربندی اتصال، استدلال‌های خط فرمان، متغیرهای محیط، شماره Portها و اجزا و Runtimeهای سایر سیستم‌ها می‌شود. این Object برای پیکربندی همسان‌سازی و مرجع استفاده شده و باید در محیط ایمن و مرکزی نگه‌داری شود.
باید کلید Hardcode شده API را به عنوان مثالی که توسط چندین برنامه کاربردی توزیع شده در Containerها استفاده شده در نظر داشت.
Sectretها: اطلاعات حساس مانند رمزهای عبور، Tokenهای Oauth و کلیدهای ssh را مدیریت و ذخیره می‌نماید. دسترسی بدون احراز هویت به این فایل‌ها باعث تحت خطر گرفتن کلاستر از جهات گوناگون می‌شود.
بیشتر بخوانید: معرفی و نحوه عملکرد Kubernetes در vSphere به همراه بررسی مزایای این تکنولوژی
چگونگی دسترسی به کلاسترهای کوبرنتیس
Kubernetes Framework از سه ارائه دهنده اصلی Cloud یعنی Amazon AWS EKS ،Google GKE و Microsoft AKS قابل دسترس است. هر Vendor دارای نسخه خود و ویژگی‌های خود است اما بطور کلی آنها به یک معماری اشاره می‌کنند. مهم است بدانیم با وجود اینکه این پست به پیاده‌سازی‌های مبتنی بر Cloud متمرکز است، Kubernetes همچنین می‌تواند بصورت On-Premises نیز پیاده‌سازی شود.
بطور کلی دو راه برای دسترسی به کلاسترهای کوبرنتیس وجود دارد: یکی از طریق Libraryهای Kubectl Client که از API استفاده می‌کند یا با ایجاد درخواست REST و این درخواست‌ها به مراحل مختلفی می‌روند که شامل احرازهویت، حق دسترسی و کنترل Admission می‌شود. مهم است بدانیم که از دید ارائه دهندگان Cloud، این فرآیندها از قبل با محصولات IAM یکپارچه هستند. در ادامه برخی موارد مرتبط دسترسی از راه دور به کلاسترهای Kubernetes شرح داده شده‌اند.
- API Transport Security Port: 6443
- احرازهویت: Client Certificates، Password، Plain Tokens، Bootstrap Tokens و JWT Tokens
- حق دسترسی: ABAC، RBAC یا Webhooks (به تنظیمات ارائه دهنده بستگی دارد)
- API Server Ports and IP Addresses Ports: 8080، 6443، 443
سایر Portهایی که باید در کلاسترهای کوبرنتیس مشاهده نمود شامل موارد زیر هستند:
همانطور که در اطلاعات بالا مشاهده می‌شود مسیر حمله به کلاسترهای Kubernetes به دو دسته تقسیم می‌شوند:
از داخل کلاستر:
- آسیب‌پذیری‌های برنامه کاربردی
- Implantکردن Container
- در معرض خطر یا قرارگیری CI/CD Devops
از خارج کلاستر:
- API فاش شده
- Kubelet فاش شده
- افشای اطلاعات
- افشای GUI مدیریت
- رد سرویس
داخل کلاستر
آسیب‌پذیری‌های برنامه‌های کاربردی ممکن است منجر به تحت خطر قرارگیری کلاستر شود زیرا آنها در محیط خارج از کنترل k8ها اجرا می‌شوند که نتیجه پیکربندی نامناسب یا راه‌اندازی با اطلاعات اعتباری بالا هستند. Implantکردن Container ممکن است باعث خسارت زدن به تمام کلاستر شود زیرا آنها با اجازه کلاستر/Pod/Node فعالیت می‌کنند. اگر یک Container که Implantشده پیاده‌سازی شود، مهاجم در داخل محیط است. تیم تحقیقات امنیت Splunk آخرین تحقیقات خود را درخصوص ریسک‌ها و مواجهه Workflowهای CI/CD Devops ارائه داده، یعنی جایی که اجزایی مانند Repositoryهای کد منبع که باید با استفاده از Pipelineهای Jenkins یا CircleCI که شامل تست‌های امنیتی است آسیب‌پذیری‌ها و خرابی‌های Library را دریافت کنند. با این حال اگر آین آسیب‌پذیری‌ها درست نشوند در تولید خود را نشان خواهند داد. یک مثال ساده کلید API Hardcode شده است که در Repository کدها جا مانده مانند Github یا یک Container که با اطلاعات اعتباری بالا پیاده‌سازی شده و به مهاجمان اجازه خواندن Secret Objectها را می‌دهد.
خارج کلاستر
با وجود اینکه ممکن است ترکیبی از راه‌های حمله داخلی و خارجی وجود داشته باشد، کلاسترهای کوبرنتیس زمانی که باید از یک برنامه کاربردی فاش شده پشتیبانی کنند از خارج دچار حمله می‌شوند. همچنین چندین مورد از پیکربندی اشتباه و آسیب‌پذیری‌ها وجود دارد که از طریق مهاجمان مورد استفاده قرار گرفته تا بطور مستقیم به کلاستر راه‌یابند مخصوصا چیزهایی مانند دسترسی به Kubelet ETCD و API.
بیشتر بخوانید: بررسی و معرفی قابليت‌های جديد vSphere و یکپارچه سازی آن با Kubernetes – قسمت اول
می‌توان با استفاده از سوابق ESCU، بطور مستقیم جستجو نموده و اطلاعات دقیق‌تری بدست آورد. در مثال‌های زیر می‌توان آخرین نسخه‌های Splunk ESCU را دید که شامل سوابق Kubernetes Scan Detection هستند.
شروع کار با اسکن شناسایی Kubernetes
به دلیل اینکه Kubernetes Frameworkبطور گسترده مورد استفاده قرار گرفته و در محیط‌های Cloud به موتور اصلی برنامه کاربردی و پیاده‌سازی سرویس تبدیل شده، مهم است مهاجمینی که سرویس‌ها و برنامه‌های کاربردی ارائه شده را بررسی می‌کنند مانیتور و شناسایی شوند. اولین گام در هرگونه حمله Remote برابر است با Footprint کردن که شامل مجموعه‌ای از فعالیت‌هاست که به مهاجم امکان بررسی سیستم‌های عملیاتی، پروتکل‌ها، برنامه‌های کاربردی و سرویس‌ها را داده و باعث می‌شود آنها از آسیب‌پذیری‌ها استفاده کنند.
این نسخه Splunk ESCU شامل یک سابقه Analytic به نام Kubernetes Scanning Activity است که Footprint کردن مهاجمان را تشخیص می‌دهد. این قابلیت شامل جستجو و شناسایی کلاستر Amazon EKS Kubernetes ،Amazon EKS Kubernetes Pod و کلاستر GCP Kubernetes cluster می‌شود.
جهت تشریح این سناریو ما کلاسترهای کوبرنتیس را مشاهده می‌کنیم که در اینترنت ارائه شده است. دسترسی مورد تحلیل و بررسی واقع شده تا درباره مهاجمی که کلاستر را اسکن می‌کند اطلاعات دقیقی کسب شود. هدف از شناسایی و تحقیق دریافتن منشا حمله است. فرض بر این است که مهاجم محیط مورد نظر را نمی‌شناسد پس فعالیت‌هایی که ذاتا ماهیت آزمون و خطا دارند مانند ضریب شکست یا موفقیت و بدافزارها نشانه اسکن‌های مربوط به حمله هستند تا مهاجم محیط را یافته یا از صحت آن با خبر شود. بنابراین باید موارد زیر را دانست:
- منبع IP کجاست
- Agent کاربر نشانه مرورگر است یا سرویس وب یا ابزار خط فرمان
- فعل HTTP استفاده شده در درخواست چیست
- کدهای پاسخگویی از این درخواست‌ها کدام‌اند (مجاز، ممنوع، یافته نشد)
- مقصد این درخواست‌ها کجاست؟
در نمودار بعدی می‌توان درخواست‌های احرازهویت نشده از IPهای اینترنت را دید که با فعل Get a responseStatus.code 403 (ممنوع) با Agent نامعموم (Checks، Go http Client، شناسایی بنر HTTP) و URLهای درخواست که مشخصا بیانگر جسنجو برای فایل یا حتی اجرای فرمان هستند، نمایش داده شده‌اند و قصد فردی که مقصد درخواست را بررسی می‌کند نشان می‌دهند. این ماهیت بررسی یا Probeکردن است.
سابقه Kubernetes Scan در این نسخه شامل جستجو برای AWS و GCP است.
این نسخه همچنین شامل یک شناسایی برای اسکن‌کردن AWS EKS Pod است. در اسکن‌کردن Pod می‌توان اطلاعات Granular را درباره درخواست‌های ویژه‌ای که Pods API را هدف قرار می‌دهند بدست آورد (/api/v1/pods). در این مثال موارد زیر قابل مشاهده است:
- IP منبع چیست: در نمودار مشخص نیست اما در جستجو معلوم است
- آیا Agent کاربر نشانه مرورگر است یا سرویس وب یا ابزار خط فرمان (curl/7.58.0, python requests/2.21.0, Mozilla 5.0…)
- کدهای پاسخگویی به این درخواست‌ها چیست (403، ممنوع)
- مقصد این درخواست کجاست (/api/v1/pods)
