مقدمه

به‌منظور حفظ امنیت و پایداری اکوسیستم Kubernetes، گروه SIG Network و کمیته پاسخ‌گویی به رخدادهای امنیتی (Security Response Committee) اعلام کرده‌اند که پروژه Ingress NGINX به‌زودی بازنشسته خواهد شد.

نگهداری این پروژه تا مارس ۲۰۲۶ به‌صورت Best-effort (یعنی بدون تضمین و در حد توان نگهدارندگان) ادامه خواهد داشت. پس از آن:

• هیچ نسخه جدیدی منتشر نخواهد شد.
• هیچ اشکالی برطرف نخواهد شد.
• هیچ به‌روزرسانی امنیتی برای رفع آسیب‌پذیری‌هایی که در آینده کشف شوند ارائه نخواهد شد.

با این حال، استقرارهای موجود Ingress NGINX همچنان به کار خود ادامه خواهند داد و فایل‌ها و بسته‌های نصب پروژه نیز همچنان در دسترس خواهند بود.

توصیه می‌کنیم به یکی از گزینه‌های جایگزین مهاجرت کنید. پیشنهاد اصلی، مهاجرت به Gateway API است که جایگزین مدرن Ingress محسوب می‌شود. اگر همچنان نیاز به استفاده از Ingress دارید، کنترلرهای جایگزین متعددی در مستندات Kubernetes معرفی شده‌اند.

در ادامه، تاریخچه، وضعیت فعلی Ingress NGINX و اقدامات پیشنهادی برای آینده شرح داده می‌شود.

درباره Ingress NGINX

Ingress نخستین راهکار ساده و کاربرپسند برای هدایت ترافیک شبکه به سمت Workloads در حال اجرا روی Kubernetes بود. امروزه Gateway API رویکرد جدیدتری است که بسیاری از همان اهداف را با قابلیت‌های بیشتر محقق می‌کند.

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

Ingress NGINX یکی از نخستین کنترلرهای Ingress بود که در سال‌های ابتدایی شکل‌گیری Kubernetes، به‌عنوان پیاده‌سازی نمونه API توسعه داده شد. این پروژه به دلیل ویژگی‌های زیر به محبوبیت فراوانی دست یافت:

• انعطاف‌پذیری بسیار بالا
• امکانات گسترده
• مستقل بودن از هر ارائه‌دهنده خاص سرویس ابری یا زیرساخت

از آن زمان تاکنون، کنترلرهای Ingress متعددی توسط گروه‌های مختلف جامعه Kubernetes و همچنین شرکت‌های فعال در حوزه Cloud Native توسعه یافته‌اند. با وجود این، Ingress NGINX همچنان یکی از پرکاربردترین کنترلرها باقی مانده و در بسیاری از پلتفرم‌های Kubernetes مدیریت ‌شده و همچنین در تعداد بی شماری از کلاسترهای مستقل کاربران مورد استفاده قرار گرفته است.

تاریخچه و چالش‌ها

گستردگی امکانات و انعطاف‌پذیری بالای Ingress NGINX، نگهداری و توسعه آن را به مرور زمان دشوار کرده است. از سوی دیگر، تغییر نگاه جامعه به امنیت نرم‌افزارهای Cloud Native نیز چالش های جدیدی ایجاد کرده است. برخی قابلیت‌هایی که در گذشته مزیت محسوب می شدند، امروز به‌عنوان آسیب‌پذیری‌های امنیتی جدی شناخته می شوند.

برای نمونه، امکان افزودن دستورات دلخواه NGINX از طریق Annotationهای snippets اکنون یک ریسک امنیتی مهم تلقی می‌شود. به عبارت دیگر، انعطاف‌پذیری‌ای که زمانی نقطه قوت پروژه بود، امروز به بدهی فنی بزرگی تبدیل شده که رفع آن تقریباً امکان‌پذیر نیست.

با وجود محبوبیت فراوان Ingress NGINX، این پروژه همواره با کمبود پشتیبان مواجه بوده است. طی سال‌های گذشته، معمولاً تنها یک یا دو نفر توسعه پروژه را در اوقات فراغت، خارج از ساعات کاری و در روزهای تعطیل انجام می دادند.

سال گذشته، نگهدارندگان Ingress NGINX اعلام کردند که قصد دارند به‌تدریج توسعه این پروژه را متوقف کرده و با همکاری جامعه Gateway API، کنترلر جایگزینی با نام InGate ایجاد کنند. متأسفانه حتی این اعلام نیز نتوانست افراد بیشتری را برای نگهداری Ingress NGINX یا توسعه InGate جذب کند.

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

وضعیت فعلی و گام‌های بعدی

در حال حاضر، نگهداری Ingress NGINX تنها به‌صورت Best-effort انجام می‌شود. گروه SIG Network و کمیته پاسخ‌گویی به رخدادهای امنیتی تمام تلاش خود را برای یافتن افراد یا منابع بیشتر به‌منظور تداوم این پروژه انجام داده‌اند، اما این تلاش‌ها نتیجه‌بخش نبوده است. به همین دلیل، برای حفظ امنیت کاربران، تصمیم به بازنشسته کردن این پروژه گرفته شده است.

در مارس ۲۰۲۶، نگهداری Ingress NGINX به طور کامل متوقف شده و پروژه رسماً بازنشسته خواهد شد. پس از آن:

• هیچ نسخه جدیدی منتشر نخواهد شد.
• هیچ اصلاحیه‌ای برای رفع اشکالات ارائه نخواهد شد.
• هیچ به‌روزرسانی امنیتی برای آسیب‌پذیری‌های جدید منتشر نخواهد شد.

همچنین، مخازن GitHub پروژه به حالت Read-only تغییر خواهند کرد و صرفاً به‌عنوان مرجع در دسترس باقی می‌مانند.

آیا استقرارهای فعلی تحت تأثیر قرار می‌گیرند؟

خیر.

استقرارهای فعلی Ingress NGINX همچنان به کار خود ادامه خواهند داد و از کار نخواهند افتاد. همچنین دارایی‌های پروژه، مانند:

• Helm Chartها
• Imageهای کانتینری

همچنان در دسترس باقی خواهند ماند.

چگونه بررسی کنیم که از Ingress NGINX استفاده می‌کنیم؟ در اغلب موارد، اگر دسترسی مدیر کلاستر را داشته باشید، می‌توانید با اجرای دستور زیر بررسی کنید که آیا Ingress NGINX در کلاستر شما در حال اجرا است یا خیر:

kubectl get pods --all-namespaces \
    --selector app.kubernetes.io/name=ingress-nginx

توصیه نهایی

گروه SIG Network و Security Response Committee به تمامی کاربران Ingress NGINX توصیه می‌کنند که در اسرع وقت مهاجرت به Gateway API یا یکی دیگر از کنترلرهای Ingress را آغاز کنند. فهرستی از گزینه‌های موجود در مستندات Kubernetes ارائه شده است، از جمله:

• Gateway API
• سایر پیاده‌سازی‌های Ingress

همچنین ممکن است شرکت یا ارائه‌دهنده سرویسی که با آن همکاری می‌کنید، راهکارهای جایگزین اختصاصی خود را نیز ارائه کرده باشد.

منابع

- Ingress NGINX Retirement: What You Need to Know - Ingress NGINX Retirement: What You Need to Know - Ingress NGINX End of Life