Ingress-nginx CVE-2025-1974: Глибокий аналіз критичних вразливостей Kubernetes

Сьогодні розробники ingress-nginx випустили патчі для ряду критичних вразливостей, які можуть дозволити зловмисникам скомпрометувати ваш кластер Kubernetes. Оскільки понад 40% адміністраторів Kubernetes використовують ingress-nginx, вжиття термінових заходів є вкрай важливим для забезпечення безпеки ваших користувачів та даних.

Передумови

Ingress є стандартним методом у Kubernetes для надання доступу до робочих Pod ззовні. Користувачі Kubernetes визначають потрібний доступ до мережі через об’єкти Ingress, а роль контролера Ingress полягає в тому, щоб інтерпретувати ці визначення та налаштовувати локальні або хмарні ресурси відповідно, гарантуючи, що додатки доступні відповідно до специфічних операційних вимог.

Серед різних контролерів Ingress, що є на ринку, ingress-nginx є виключно програмним рішенням, яке підтримується спільнотою Kubernetes. Відомий своєю гнучкістю і простотою у використанні, ingress-nginx сьогодні розгорнуто в понад 40% кластерів Kubernetes по всьому світу. Цей контролер працює, перетворюючи специфікації Ingress у конфігурації для nginx, високонастроювального веб-сервера з відкритим вихідним кодом. Nginx потім маршрутизує запити до бекенд-додатків, роблячи правильне налаштування параметрів конфігурації критично важливим. Неправильні налаштування можуть призвести до вразливостей, що дозволяє зловмисникам маніпулювати nginx у спосіб, якого не передбачалося.

Сьогодні виправлені вразливості

Сьогоднішній реліз вирішує п’ять критичних вразливостей, включаючи чотири проблеми, які покращують обробку ingress-nginx певних фрагментів конфігурації nginx. Якщо їх не виправити, ці проблеми можуть дозволити зловмисно створеному об’єкту Ingress змусити nginx випадково розкрити або вивести Секрети, доступні контролеру. Оскільки ingress-nginx за замовчуванням має доступ до Секретів у кластері, ігнорування цих патчів може надати зловмиснику можливість швидко підвищити свої повноваження і потенційно захопити кластер.

Найбільш тривожною з цих вразливостей є CVE-2025-1974, яка має рейтинг CVSS 9.8. Ця вразливість експлуатує помилки ін’єкції конфігурацій через функцію Validating Admission Controller, що означає, що будь-хто в мережі Pod—навіть без адміністративних привілеїв—може спровокувати захоплення кластера. У багатьох розповсюджених сценаріях хмарних та корпоративних мереж мережа Pod доступна для майже всіх робочих навантажень, що створює велику поверхню для експлуатації.

У відповідь команда ingress-nginx випустила версії v1.12.1 та v1.11.5, які містять патчі для всіх п’яти вразливостей.

Ваші подальші дії

По-перше, перевірте, чи використовують ваші кластери ingress-nginx. Зазвичай ви можете підтвердити його присутність, виконавши команду нижче з правами адміністратора кластера:

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

Якщо ви використовуєте ingress-nginx, будь ласка, надайте пріоритет усуненню цих вразливостей.

Найпростіший та найбільш ефективний варіант — оновити до останньої версії патчу. Це оновлення виправляє всі п’ять вразливостей за один крок.

Для середовищ, де термінове оновлення є складним, ви можете зменшити ризик, вимкнувши функцію Validating Admission Controller у ingress-nginx:

• Якщо встановлено через Helm:
  
  • Перевстановіть, встановивши значення Helm на controller.admissionWebhooks.enabled=false

• Якщо встановлено вручну:
  
  • Видаліть ValidatingWebhookConfiguration з ім’ям ingress-nginx-admission
  • Редагуйте Deployment або DaemonSet для ingress-nginx-controller, видаливши аргумент --validating-webhook з конфігурації контейнера

Не забудьте знову увімкнути Validating Admission Controller після оновлення, щоб відновити його переваги, попереджаючи користувачів про неправильні конфігурації.

Глибоке занурення: Як Ingress-nginx інтегрується з Nginx

В основі, ingress-nginx виступає посередником між визначеннями Ingress у Kubernetes та конфігураціями nginx. Він аналізує специфікації Ingress, визначені користувачем, у детальний файл конфігурації nginx. Цей файл керує тим, як обробляються вхідні мережеві пакети і маршрутизуються до призначених бекенд-сервісів. Завдяки розширеним функціям, таким як завершення TLS, переписування URL та балансування навантаження, nginx стає потужним інструментом, але таким, що потребує надійної валідації, щоб запобігти неправильним налаштуванням, які можуть призвести до загроз безпеці.

Вразливість CVE-2025-1974 використовує недоліки в цьому процесі трансляції, що дозволяє зловмисникам у мережі Pod віддалено вводити шкідливі параметри конфігурації. Експерти зазначають, що правильне управління обсягом конфігурації та правами доступу в контексті nginx є надзвичайно важливим, оскільки навіть незначні помилки можуть призвести до серйозних порушень безпеки.

Експертні поради: Забезпечення безпеки контролерів Ingress у Kubernetes

Фахівці з безпеки підкреслюють, що управління контролерами Ingress — це не тільки підтримка програмного забезпечення в актуальному стані, але й забезпечення надійних практик розгортання. Згідно з думкою експертів галузі, рекомендуються наступні найкращі практики:

• Регулярно перевіряйте конфігурації Ingress, щоб переконатися, що тільки уповноважені особи мають права на створення.
• Впроваджуйте додаткову сегментацію мережі для мережі Pod, щоб зменшити ризики бічного руху.
• Старанно розгортайте політики контролю доступу на основі ролей (RBAC), щоб обмежити, хто може визначати або змінювати ресурси Ingress.
• Моніторте трафік ingress та журнали в реальному часі, використовуючи централізовані рішення журналювання та системи SIEM для виявлення незвичних патернів доступу.

Ці заходи разом із своєчасними оновленнями програмного забезпечення забезпечують багаторівневий захист, що мінімізує потенційний вплив майбутніх вразливостей.

Майбутні тенденції: Підвищення безпеки Ingress у Kubernetes

У перспективі екосистема Kubernetes, ймовірно, ще більше акцентуватиме увагу на зміцненні безпеки компонентів Ingress. Зі зростанням впровадження архітектур мікросервісів та багатохмарних розгортань, складність і профіль ризику налаштувань Ingress продовжуватимуть еволюціонувати.

Останні обговорення в рамках Спільноти реагування на безпеку Kubernetes (KSRC) свідчать про те, що в майбутніх версіях можуть бути включені внутрішні перевірки безпеки та краща інтеграція з централізованими системами аутентифікації. Крім того, деякі пропозиції підтримують більш детальні контролі доступу на рівні Ingress, що дозволить адміністраторам визначати політики безпеки разом з правилами маршрутизації.

Ці перспективні заходи спрямовані на зменшення залежності від обхідних шляхів, таких як вимкнення критичних функцій, сприяючи створенню більш безпечної та стійкої інфраструктури, здатної краще витримувати складні атаки.

Висновок, подяки та подальше читання

Вразливості, особливо CVE-2025-1974, становлять серйозну загрозу для користувачів Kubernetes. Якщо ви покладаєтеся на ingress-nginx, важливо діяти швидко—або оновити до виправлених версій, або тимчасово зменшити ризик, вимкнувши вразливу функцію.

Особлива подяка Ніру Офелду, Сагі Цадіку, Ронену Шустіну та Хіллаю Бен-Сасону з Wiz за їх відповідальне розкриття вразливостей, а також членам SRC Kubernetes і розробникам ingress-nginx, Марко Еберту та Джеймсу Стронгу, за їх оперативні зусилля з виправлення.

Для додаткового контексту про обслуговування ingress-nginx та майбутні напрямки зверніться до обговорення в цій проблемі на GitHub або відвідайте презентацію Джеймса та Марко на KubeCon/CloudNativeCon EU 2025.

Додаткову інформацію про окремі вразливості можна знайти в відповідних проблемах на GitHub: CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, та CVE-2025-1974.

Джерело: Блог Kubernetes