AWS منسوخ‌سازی aws-auth را اعلام کرد؛ اکثریت خوشه‌ها به‌روز نشده‌اند

AWS نگاشت هویت‌های IAM به مجوزهای خوشه در EKS — معروف به aws-auth ConfigMap — را منسوخ کرده و جایگزین‌های مبتنی بر API و مدل‌های هویتی دقیق‌تر را توصیه می‌کند. گزارش امنیتی کوبرنتیز 2025 نشان می‌دهد حدود 81٪ خوشه‌های EKS هنوز از این روش دستی و قابل خطا استفاده می‌کنند که ریسک نفوذ، امتیازات بیش‌ازحد و کندی در استقرار را افزایش می‌دهد.

چه تغییراتی اعمال شده؟

روش مرسوم مبتنی بر ویرایش دستی ConfigMap و نگاشت مستقیم کاربران و نقش‌های IAM به نقش‌های Kubernetes محدودیت‌هایی دارد: پیگیری تغییرات سخت است، خودکارسازی دشوار است و احتمال پیکربندی ناامن بالاست. هم‌اکنون AWS به‌سمت راه‌حل‌های مبتنی بر API، OIDC و مکانیزم‌هایی می‌رود که مدیریت مرکزی، ثبت رویدادها و پیاده‌سازی اصل least-privilege را ساده می‌کنند. برای اطلاعات فنی بیشتر به مستندات رسمی AWS EKS مراجعه کنید.

اهمیت مسأله

  • حسابرسی دشوار: تغییرات دستی در ConfigMapها به‌سختی قابل ردگیری و بازبینی هستند و ممیزی‌ها را پیچیده می‌کنند.
  • پیکربندی‌های ناامن: نگاشت‌های گسترده می‌توانند امتیازات بیش از حد ایجاد کنند و مهاجمان را به API سرور نزدیک‌تر کنند.
  • تأخیر در استقرار: سازمان‌ها به‌خاطر نگرانی‌های امنیتی مرتبط با کوبرنتیز، استقرارهای حساس را به تعویق می‌اندازند یا کند می‌کنند.

ریشه مشکل: چرا شیوه‌های سنتی جواب نمی‌دهند

مدل‌های امنیتی دوران ماشین‌های مجازی بر موجودیت‌های پایدار و آدرس‌های IP ثابت اتکا می‌کردند. کوبرنتیز اما محیطی پویا و متغیر دارد: پادها مکرراً ساخته و حذف می‌شوند، بارکاری بین گره‌ها جابه‌جا می‌شود و مقیاس‌پذیری خودکار ساختار حمله را تغییر می‌دهد. تحلیل سطح حمله در مدل‌های مدرن باید لایه‌ای و مبتنی بر چهار حوزه اصلی باشد: کد، کانتینر، خوشه و سرویس‌های ابری. ضعف در هر لایه می‌تواند سریعاً به نفوذ یا گسترش جانبی منجر شود.

برای مروری فنی روی کوبرنتیز می‌توانید صفحه Kubernetes در ویکی‌پدیا را ببینید.

نقاطی که اغلب نادیده گرفته می‌شوند

  • لایهٔ کانتینر: زنجیره تأمین تصویر هدف اصلی است؛ تصاویر باید از کد تا اجرا به‌صورت پیوسته اسکن و راستی‌آزمایی شوند.
  • لایهٔ خوشه: چرخهٔ عمر خوشه، پیکربندی شبکه شرق–غرب و سیاست‌های شبکه‌ای اغلب کم‌توجهی می‌شوند؛ پیش‌فرض‌ها معمولاً ارتباط آزاد بین پادها را امکان‌پذیر می‌کنند.
  • کنترل دسترسی: نگارش‌های دستی مانند aws-auth باعث تخصیص امتیازات بیش از ضروری می‌شوند و شناسایی نشانه‌های حمله را به تأخیر می‌اندازند.

گام‌های عملی برای کاهش ریسک و مهاجرت امن

پیشنهادات زیر برای تیم‌های زیرساخت و امنیت طراحی شده تا مهاجرت از aws-auth به راهکارهای مبتنی بر API را ساختاریافته و ایمن انجام دهند:

  1. شناسایی و ممیزی

    تمام خوشه‌ها را اسکن کنید تا وجود ConfigMapهای aws-auth ثبت شود. نقش‌ها و کاربران نگاشت‌شده را مستندسازی و سطح دسترسی هر مورد را تحلیل کنید.

  2. برنامهٔ مهاجرت با آزمون مرحله‌ای

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

  3. انتخاب مکانیزم هویتی کمترین امتیاز

    راه‌حل‌هایی را پیاده کنید که مدیریت مرکزی، خودکارسازی و مدل least-privilege را پشتیبانی کنند: فعال‌سازی OIDC، استفاده از IAM Roles for Service Accounts یا جایگزین‌های پیشنهادی AWS.

  4. تقویت RBAC و سیاست‌های شبکه‌ای

    نقش‌ها را بازطراحی کنید و رول‌های محدود تعریف کنید. سیاست‌های NetworkPolicy را برای محدودسازی ترافیک شرق–غرب اعمال کنید. مستندات شبکه کوبرنتیز را در این صفحه مطالعه کنید.

  5. ابزارهای اسکن و پایش در خط لوله

    اسکن تصاویر (SCA)، بررسی پیکربندی با ابزارهایی مانند kube-bench و پایش زمان اجرا با Falco را در CI/CD بگنجانید. اطلاعات درباره Falco در falco.org و درباره سیاست‌گذاری در Open Policy Agent موجود است.

  6. حسابرسی و لاگینگ متمرکز

    ثبت دسترسی‌ها و تغییرات را متمرکز کنید تا الگوهای غیرمعمول سریع‌تر شناسایی شوند و امکان واکنش خودکار فراهم گردد.

  7. چرخش و کاهش اعتبارنامه‌ها

    کلیدها و توکن‌هایی که بیش از حد گسترده یا قدیمی هستند را بازنگری کرده و دوره‌ای بچرخانید. دسترسی‌های موقتی و مبتنی‌بر نیاز را جایگزین دسترسی‌های دائم کنید.

هزینهٔ به تأخیر انداختن مهاجرت

ادامهٔ استفاده از مکانیزم‌های دستی صرفاً ریسک نفوذ و افشای داده را افزایش نمی‌دهد؛ هزینه‌های عملیاتی را هم بالا می‌برد: افزایش زمان بررسی حوادث، دشواری در ردیابی تغییرات و تأخیر در استقرار ویژگی‌های حیاتی. سازمان‌هایی که مهاجرت را به تعویق می‌اندازند در معرض تهدیدهایی قرار می‌گیرند که می‌تواند به دسترسی ناخواسته به API سرور یا گسترش جانبی در خوشه منتج شود.

چشم‌انداز و توصیه نهایی

حرکت AWS به سمت روش‌های مبتنی بر API فرصت مناسبی برای بازطراحی کنترل دسترسی در EKS و پیاده‌سازی اصول امنیت بومیِ ابری است. شروع فوری به مهاجرت و مطابق‌سازی با مدل‌های هویتی جدید، هم ریسک را کاهش می‌دهد و هم سرعت انتشار را افزایش می‌دهد. فهرست خوشه‌ها و نگاشت‌های aws-auth را امروز بررسی کنید و یک برنامهٔ مهاجرتی مشخص برای حداکثر سه ماه آینده تدوین نمایید.

چک‌لیست سریع

  • شناسایی خوشه‌های درگیر و مستندسازی نگاشت‌ها
  • آزمون مهاجرت در محیط‌های غیرتولیدی
  • فعال‌سازی OIDC و استفاده از IAM roles for service accounts
  • تعریف RBAC محدود و اعمال NetworkPolicy
  • گنجاندن اسکن و پایش در CI/CD
  • راه‌اندازی لاگینگ و حسابرسی متمرکز
  • چرخش دوره‌ای کلیدها و توکن‌ها