Наші курси
Новини

Вразливість в Ingress-Nginx: кластери Kubernetes під загрозою

У світі DevOps нечасто трапляються ситуації, коли хочеться поставити все на паузу й терміново апдейтнути кластери. Але цей випадок — саме такий. 

Якщо ти працюєш із Kubernetes і використовуєш Ingress NGINX Controller, саме час відкласти каву й зробити важливу перевірку: твій кластер — серед тих 43% інтернет-фейсингових, які наражаються на ризик повного захоплення?

Що сталося?

Команда дослідників із Wiz виявила серію критичних вразливостей у компоненті admission controller популярного Ingress NGINX Controller. Вразливості настільки серйозні, що об’єднано їх під гучною назвою IngressNightmare.

В чому вся суть? Хакер може віддалено виконати довільний код на поді з Ingress NGINX, навіть не маючи жодних прав доступу чи облікових даних. І все це — через звичайний Ingress-обʼєкт, якщо admission controller доступний через мережу. Нагадує страшилку? Це реальність.

Які можуть бути наслідки?

Ingress NGINX Controller вразливий через відкриту мережеву точку (адмішн-контролер), яка:

// не автентифікується
// має доступ до всіх Secrets у кластері
// використовується у понад 40% кластерах Kubernetes

Як результат — достатньо мати доступ до Pod-мережі, і… кластер у руках хакера. Повністю.

Найнебезпечніша CVE-ка: CVE-2025-1974

Вона має оцінку CVSS 9.8 з 10. Це максимум для багів, які дозволяють віддалене виконання коду. Вразливість дозволяє впроваджувати шкідливу nginx-конфігурацію через admission controller, що валідує конфіги до того, як вони застосуються.

Якщо ти працюєш із Kubernetes, то вже зрозумів, що це — справжній катаклізм. А якщо ти ще тільки вчишся чи плануєш світчнутися в DevOps, то тримай це як чудову ілюстрацію, навіщо DevOps-інженерам знати безпеку на проді.

Як так вийшло?

Ingress NGINX Controller — це міст між Kubernetes та nginx-конфігураціями. Щоб уникнути факапів при конвертації правил Ingress у конфіги nginx, розробники реалізували механізм валідації — admission webhook.

Ідея хороша: перед тим, як nginx застосує правила, admission controller перевіряє, чи вони валідні. Але реалізація… Проблема в тому, що цей admission controller:

// запускається з правами, які дозволяють читати всі секрети
// не вимагає автентифікації
// і… вразливий до впровадження конфігів, які запускають довільний код

Отримуємо не просто RCE, а RCE з адміндоступом до всього кластеру.

Де найбільший ризик?

  1. Kubernetes кластери, які використовують Ingress NGINX Controller версій < 1.12.1.
  2. Кластери, де admission controller доступний ззовні (що, як зʼясувалося, — масове явище).
  3. Внутрішні мережі, де Pod-и можуть комунікувати з admission controller без обмежень.

За оцінкою Wiz, таких кластерів — понад 6 500, включаючи й серед Fortune 500.

Що тобі робити прямо зараз?

Спочатку визнач, чи твої кластери використовують ingress-nginx. У більшості випадків ти можеш перевірити це, запустивши kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx з дозволами адміністратора кластера.
Якщо так, твої дії описані далі.

Оновитись до версій 1.12.1 або 1.11.5. Це обовʼязково. Прямо зараз. Навіть якщо на дворі 3:27 ночі. Особливо, якщо ти відповідальний за прод.

Якщо апдейт неможливий:
  1. Вимкни Validating Admission Controller, якщо він не критичний для роботи.
  2. Введи сувору мережеву політику, щоб лише Kubernetes API Server мав доступ до admission controller.
  3. Використовуй сканери типу Nuclei для виявлення відкритих точок доступу.

Якщо встановлював ingress-nginx через Helm, виконай команду:

helm upgrade --set controller.admissionWebhooks.enabled=false

Якщо вручну:

  1. Видали ValidatingWebhookConfiguration з назвою ingress-nginx-admission
  2. Видали флаг –validating-webhook у Deployment або DaemonSet.

Не забудь повернути все назад після апдейту. Бо admission controller — це теж safeguard. Відключив — протестував — оновив — увімкнув знову.

Що це значить для DevOps-інженера?

Цей кейс — мастхев для будь-кого, хто працює або тільки занурюється у Kubernetes. На курсі «Kubernetes. Практикум з адміністрування» від ITEDU ми не просто вчимо піднімати кластери — ми показуємо, як захищати їх від реальних атак, на прикладі таких кейсів, як IngressNightmare. І так — Ingress, admission controller, CVE-шки, RCE, pod-мережа — це все в програмі курсу.

Цей інцидент — не виклик для DevOps-спільноти. Це нагадування, що ми не просто автоматизуємо деплой — ми відповідаємо за безпеку продакшну. 

Залишити відповідь

Схожі статті

Дякуємо, що поділились