آخرین اخبار
همهٔ اخبار
امنیت ابری گزارش بحرانیت ۶/۱۰

چگونه اپراتورهای Kubernetes به درگاه‌های ورود مهاجمان تبدیل می‌شوند؟

چگونه اپراتورهای Kubernetes به درگاه‌های ورود مهاجمان تبدیل می‌شوند؟

اپراتورهای کوبرنتیز (Kubernetes Operators) برای کاهش هزینه‌های عملیاتی و اتوماسیون مدیریت کلاسترها طراحی شده‌اند و در واقع مانند مهندسان SRE خودکار عمل می‌کنند. با این حال، اتکای شدید این ابزارها به حساب‌های خدماتی (Service Accounts) با دسترسی‌های بالا، یک نقطه ضعف امنیتی جدی و اغلب نادیده گرفته شده ایجاد کرده است.

معرفی OperTraitor: تحلیل ریسک مبتنی بر LLM

برای شناسایی و مقابله با تهدیداتی که از این نقاط ضعف بهره‌برداری می‌کنند، ابزاری متن‌باز به نام OperTraitor توسعه یافته است. این موتور تحلیل که از مدل‌های زبانی بزرگ (LLM) بهره می‌برد، پیکربندی‌های RBAC (کنترل دسترسی مبتنی بر نقش) را مستقیماً از اپراتورهای نصب شده و کاتالوگ OperatorHub دریافت می‌کند. سپس تفاوت بین قابلیت‌های مستند شده در داکیومنت‌های اپراتور و دسترسی‌های واقعی اعطا شده به آن را محاسبه می‌کند.

تحقیقات نشان می‌دهد که توسعه‌دهندگان برای اطمینان از اجرای بدون نقص اپراتورها، اغلب دسترسی‌های گسترده و Wildcard در RBAC تعریف می‌کنند. این اقدام باعث می‌شود اجزای مورد اعتماد به طور ناخواسته به Backdoorهای خاموشی تبدیل شوند که برای مهاجمان بسیار جذاب هستند.

تکامل تهدیدات: عصر اپراتورهای Agentic

در حالی که مشکل بنیادین مربوط به پیکربندی‌های RBAC است، با حرکت صنعت به سمت اپراتورهای Agentic (سیستم‌های خودمختاری که با استفاده از LLM و استدلال‌های AI کلاسترها را مدیریت می‌کنند)، ریسک‌ها به شدت افزایش می‌یابد. در این اکوسیستم، دسترسی‌های بیش از حد دیگر صرفاً یک اشتباه پیکربندی نیستند، بلکه به بردارهای حمله فعال تبدیل می‌شوند که می‌توانند به طور خودکار از محیط کلاستر بهره‌برداری کنند.

تحلیل زنجیره تأمین و نقاط ضعف OperatorHub

بررسی‌ها نشان می‌دهد که OperatorHub مملو از اجزای نرم‌افزاری رها شده و دارای دسترسی‌های بیش از حد است. بسیاری از فروشندگان نسخه‌های امن را تنها از طریق Helm Charts یا GitHub منتشر می‌کنند، اما نسخه‌های قدیمی و آسیب‌پذیر همچنان از طریق Operator Lifecycle Manager (OLM) در دسترس هستند. این موضوع باعث می‌شود کاربران بدون اطلاع از ریسک‌ها، اپراتورهای قدیمی را با چند کلیک ساده مستقر کنند.

مطالعات موردی (Case Studies)

۱. دسترسی بیش از حد به Secretها (اپراتور Prometurbo – IBM):

ابزار OperTraitor متوجه شد که حساب خدماتی این اپراتور به جای محدود شدن به Namespace خود، به یک ClusterRole متصل است که اجازه get، list و watch روی تمامی Secretها در سطح کلاستر را می‌دهد. این یعنی در صورت به خطر افتادن اپراتور، مهاجم می‌تواند توکن‌های مدیریت، رمز عبور دیتابیس و گواهینامه‌های TLS تمام Namespaceهای دیگر را استخراج کند. این آسیب‌پذیری با شناسه CVE-2026-6389 و امتیاز CVSS 8.8 ثبت شد و سپس توسط IBM اصلاح گردید.

۲. تضاد بین امنیت و تجربه کاربری (اپراتور Datadog):

در مورد اپراتور Datadog، دسترسی‌های گسترده‌ای به Secretها و منابع RBAC مشاهده شد. شرکت Datadog توضیح داد که به دلیل ماهیت تعریف‌شده توسط کاربر (User-defined) برای نام Secretها، پیش‌بینی دقیق آن‌ها قبل از استقرار غیرممکن است. این مورد نشان‌دهنده چالش پیچیده بین اعمال سخت‌گیرانه امنیت و ارائه تجربه کاربری (UX) روان است.

راهکارهای کاهش ریسک و مقابله

برای ایمن‌سازی زیرساخت‌های کوبرنتیز، استراتژی‌های دفاعی زیر توصیه می‌شود:

  • اعمال اصل کمترین دسترسی (PoLP): بازبینی دقیق تمامی ClusterRoleها و محدود کردن دسترسی‌ها به حداقل مورد نیاز برای عملکرد اپراتور.
  • حسابرسی (Audit) مستمر: استفاده از ابزارهایی برای شناسایی دسترسی‌های Wildcard و بررسی تطابق دسترسی‌های اعطا شده با مستندات فنی.
  • مدیریت هویت‌های غیرانسانی: نظارت دقیق بر Service Accountها با همان سخت‌گیری که برای مدیران انسانی اعمال می‌شود.
  • اعتبارسنجی منابع OperatorHub: بررسی وضعیت به‌روز بودن و فعال بودن پشتیبانی اپراتورها پیش از استقرار در محیط عملیاتی.