در محیط‌های ابری Google Cloud، مدیریت کلیدهای Service Account به دلیل ریسک نشت داده‌ها (Secret Sprawl) و دشواری در چرخش (Rotation) اعتبارنامه‌ها، به یک چالش امنیتی تبدیل شده است. برای حل این مشکل، گوگل ابزاری به نام Google Kubernetes Config Connector (KCC) را معرفی کرده است که به توسعه‌دهندگان اجازه می‌دهد بدون نیاز به داشتن اعتبارنامه‌های مستقیم ابری، منابع GCP را از طریق فایل‌های پیکربندی Kubernetes مدیریت کنند.
مکانیسم عملکرد KCC و ریسک‌های مرتبط
ابزار KCC به عنوان یک Operator در کلاستر GKE اجرا می‌شود و تغییرات در فایل‌های YAML را رصد کرده و از طریق APIهای گوگل، منابع مربوطه را ایجاد یا به‌روزرسانی می‌کند. این سیستم از Workload Identity استفاده می‌کند و تمام عملیات را با استفاده از یک Service Account مرکزی (KCC GSA) انجام می‌دهد. از آنجایی که KCC ممکن است زیرساخت‌های متعددی را مدیریت کند، اغلب دسترسی‌های گسترده‌ای مانند role/owner یا roles/resourcemanager.organizationAdmin به این حساب اختصاص می‌یابد.
تشریح حمله ConfigConfusion
آسیب‌پذیری ConfigConfusion که توسط Justin O’Leary کشف شده است، از یک مشکل کلاسیک امنیتی به نام Confused Deputy نشأت می‌گیرد. در این سناریو، KCC به عنوان «نماینده‌ای گیج شده» عمل می‌کند؛ زیرا دستورات را از کاربرانی با دسترسی محدود در Kubernetes دریافت کرده و آن‌ها را با سطح دسترسی بالای خود در Google Cloud اجرا می‌کند.
- مسیر حمله: یک کاربر با دسترسی محدود به Namespace در Kubernetes، یک منبع
IAMPolicyMemberرا تعریف و ارسال می‌کند. - اجرای عملیات: KCC این درخواست را دریافت کرده و با استفاده از Service Account قدرتمند خود، تغییرات IAM را در سطح سازمان اعمال می‌کند.
- نتیجه: مهاجم می‌تواند بدون داشتن هیچ‌گونه اعتبارنامه مستقیم GCP، نقش
roles/ownerرا برای خود در سطح کل سازمان فعال کند و کنترل کامل زیرساخت را به دست بگیرد.
چالش‌های مدیریتی و پاسخ گوگل
گوگل اعلام کرده است که KCC طبق طراحی خود عمل می‌کند و این موضوع یک تصمیم پیکربندی (Configuration Decision) توسط مدیر سیستم است. با این حال، مشکل اصلی در مستندات است که ارتباط بین «اجازه ایجاد منابع IAM در Kubernetes» و «سطح دسترسی Service Account در GCP» را به روشنی بیان نمی‌کند.
راهکارهای کاهش ریسک (Mitigation)
برای جلوگیری از این نوع Privilege Escalation، مدیران SOC و مهندسان امنیت باید هر دو سمت شکاف احراز هویت را محدود کنند:
- محدود کردن دسترسی‌های KCC: به جای اعطای دسترسی‌های سطح سازمان (Organization-level)، از اصل Least Privilege استفاده کرده و فقط دسترسی‌های ضروری را به KCC GSA اختصاص دهید.
- کنترل دسترسی در Kubernetes: دسترسی کاربران به ایجاد منابع حساس (مانند
IAMPolicyMember) در Namespaceهای تحت مدیریت KCC را به شدت محدود کنید.
