Питання безпеки щодо CRD в Istio з багатокористувацькою архітектурою на основі просторів імен

Розгляд вразливостей типу "людина посередині" в багатокористувацьких налаштуваннях на основі просторів імен.

Mar 21, 2026 | Від Lorin Lehawany - ERNW, Sven Nobis - ERNW

Проєкт Istio хоче розглянути можливий сценарій атаки типу “людина посередині” (MITM), у якому VirtualService може перенаправляти або перехоплювати трафік у межах сервісної сітки. Це стосується кластерів з багатокористувацькою архітектурою на основі просторів імен, де орендарі мають дозволи на розгортання ресурсів Istio (networking.istio.io/v1).

У цьому дописі висвітлюються ризики використання Istio в кластерах з багатокористувацькою архітектурою та пояснюється, як користувачі можуть зменшити ці ризики та безпечно експлуатувати Istio у своїх розгортаннях.

Зверніть увагу, що проблеми виходять за межі кластера навіть у розгортанні “одна сітка з кількома кластерами”.

Поведінка, описана в цьому дописі, застосовується до Istio версії 1.29.0 та до всіх версій з моменту впровадження опції mesh gateway у ресурсі VirtualService.

Передумови

Багатокористувацька архітектура на основі просторів імен

Простори імен у Kubernetes забезпечують механізм організації груп ресурсів у межах кластера. Простори імен надають логічну абстракцію, яка дозволяє командам, застосункам або середовищам ділити один кластер, ізолюючи свої ресурси за допомогою таких механізмів, як мережеві політики (Network Policies), RBAC тощо.

У цьому дописі ми зосереджуємося на використанні Istio в кластерах, де кілька орендарів ділять один кластер і сервісну сітку, і можуть розгортати ресурси Istio (networking.istio.io/v1) у своїх просторах імен, покладаючись на межі просторів імен для ізоляції.

Маршрутизація трафіку в Istio

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

Одним із центральних ресурсів для цієї мети є VirtualService. VirtualService визначає набір правил маршрутизації, які визначають, як обробляються запити до хостів, зазначених у spec.hosts.[]. Ці правила можуть відповідати запитам на основі таких властивостей, як HTTP-заголовки, шляхи або порти, а потім направляти трафік до одного або кількох сервісів призначення.

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

На відміну від новішого Kubernetes Gateway API, ці CRD були створені та фактично стабілізовані ще до того, як RBAC на основі просторів імен зʼявився в Kubernetes. Таким чином, багатокористувацька архітектура на основі просторів імен, яка ділить одну й ту саму сервісну сітку, не була частиною моделі загроз на той час. З впровадженням RBAC зʼявилися такі багатокористувацькі середовища. Тому важливо підкреслити та вирішити проблеми безпеки, повʼязані з цими архітектурами.

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

Атаки “людина посередині” через VirtualService

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

Зловмисник, який має дозвіл на створення або зміну ресурсів VirtualService, може зловживати цією поведінкою, визначаючи правила маршрутизації для довільних хостів. Коли параметр сервісної сітки mesh встановлено в розділі gateways специфікації, правила маршрутизації застосовуються до всіх проксі sidecar у сітці (незалежно від їхнього простору імен).

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

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

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

Джерельний сервіс надішле запит до сервісу, контрольованого зловмисником, замість сервісу призначення, оскільки VirtualService перевизначає стандартну поведінку. Взаємна автентифікація TLS Istio тут не допомагає, оскільки проксі ідентифікує сервіс, контрольований зловмисником, як легітимний пункт призначення для перезаписаного імені хосту. Однак пересилання цього трафіку до сервісу призначення для читання або модифікації комунікації між двома сервісами є більш складним для зловмисника, оскільки він не може обійти функції безпеки рівня 4 та рівня 7 Istio. Оскільки зловмисник перехоплює комунікацію, наскрізне шифрування та автентифікація між джерельним і сервісом призначення порушуються. Таким чином, запит, пересланий від сервісу, контрольованого зловмисником, до сервісу призначення, автентифікується як запит від сервісу, контрольованого зловмисником. В результаті політики авторизації, налаштовані на сервісі призначення, можуть відхилити запит. Крім того, сервіс призначення побачить ідентичність сервісу, контрольованого зловмисником, у заголовку X-Forwarded-Client-Cert, і автентифікація від джерельного сервісу буде втрачена.

Чому виникає така поведінка?

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

Сервісна сітка Istio логічно розділена на панель даних і панель управління. Панель управління Istio агрегує конфігурацію маршрутизації з усіх ресурсів VirtualService і розподіляє отриману конфігурацію на проксі Envoy sidecar, які складають панель даних. Ці проксі потім локально застосовують правила маршрутизації для трафіку, який вони обробляють, див. також Архітектура Istio.

Коли VirtualService налаштовано як mesh gateway, його правила маршрутизації застосовуються до всіх sidecar у сітці, включаючи внутрішній трафік між сервісами. Оскільки ефекти цієї конфігурації не обмежуються простором імен, у якому знаходиться VirtualService, конфігурація, створена в одному просторі імен, може відповідати запитам, що походять від робочих навантажень в інших просторах імен.

Помʼякшення наслідків та найкращі практики

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

Рекомендоване помʼякшення: перехід на новіший Gateway API

В ідеалі, дозволи на створення або зміну ресурсів мережевої взаємодії Istio (networking.istio.io/v1 та security.istio.io/v1) повинні бути обмежені операторами платформи, відповідальними за глобальну маршрутизацію.

Як альтернативу, оператори можуть надати орендарям доступ до нового Gateway API, який розроблено з урахуванням безпечної підтримки міжпросторових імен. Однак оператори платформи все одно повинні контролювати доступ до спільних ресурсів, таких як шлюзи.

Обмеження конфігурації можна реалізувати як додатковий контроль.

Помʼякшення наслідків у застарілих налаштуваннях

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

Одним із способів помʼякшення такого виду атак є налаштування Обмеження конфігурації. Наприклад, обмежити Egress listener у кожному просторі імен довіреними просторами імен. Однак це помʼякшить проблему лише в режимі sidecar та ambient mode з waypoints, але не в ambient mode лише на рівні L4, а також не для хостів, налаштованих при використанні Istio Gateway.

Ще одним способом помʼякшення такого виду атак є впровадження політики допуску, яка обмежує, які хости можна використовувати в секції host для кожного орендаря. Це також помʼякшить проблему в ambient mode.

Висновок

Як показано в цьому дописі, опція mesh gateway в Istio дозволяє правилам, визначеним в одному просторі імен, впливати на трафік інших просторів імен. У налаштуваннях багатокористувацької роботи на основі простору імен або при запуску єдиної сітки в кількох кластерах така поведінка може піддавати сітку сервісів атакам з боку зловмисників, наприклад, дозволяючи MITM-атаки, як пояснено в цьому дописі.

Istio не претендує (і не прагне претендувати) на жорстку багатокористувацьку роботу на основі простору імен, оскільки проєкт обрав компроміс, який полегшує впровадження. Тому оператори, які покладаються на такий тип багатокористувацької роботи, повинні оцінити ризики, повʼязані з їхньою архітектурою, і усунути слабкі місця, наприклад, видаливши непотрібні дозволи RBAC і впровадивши суворі контролі допуску.