Панель даних ambient

В режимі ambient навантаження може потрапляти в 3 категорії:

1. Out of Mesh: стандартний pod без будь-яких функцій mesh. Istio та панель даних ambient не активовані.
2. In Mesh: pod, який включено в панель даних ambient і який має перехоплення трафіку на рівні Layer 4 за допомогою ztunnel. У цьому режимі можна застосовувати політики L4 для трафіку podʼа. Цей режим можна активувати, встановивши мітку istio.io/dataplane-mode=ambient. Див. мітки для отримання додаткових деталей.
3. In Mesh, Waypoint enabled: pod, який є в mesh та має розгорнутий проксі waypoint. У цьому режимі можна застосовувати політики L7 для трафіку podʼа. Цей режим можна активувати, встановивши мітку istio.io/use-waypoint. Див. мітки для отримання додаткових деталей.

Залежно від категорії, до якої належить навантаження, шлях трафіку буде різним.

Маршрутизація в mesh

Вихідний трафік

Коли pod у mesh ambient робить вихідний запит, він буде прозоро перенаправлений до локального на вузлі ztunnel, який визначить, куди і як переслати запит. Загалом, маршрутизація трафіку поводитися так само як і у Kubernetes; запити до Service будуть надіслані до точки доступу в межах Service, тоді як запити безпосередньо до IP Pod підуть безпосередньо до цього IP.

Однак, залежно від можливостей призначення, буде відбуватися різна поведінка. Якщо призначення також додане в mesh або має можливості проксі Istio (такі як sidecar), запит буде оновлено до зашифрованого тунелю HBONE. Якщо призначення має проксі waypoint, окрім оновлення до HBONE, запит буде пересланий до цього waypoint для застосування політик L7.

Зверніть увагу, що у випадку запиту до Service, якщо сервіс має waypoint, запит буде надісланий до його waypoint для застосування політик L7 до трафіку. Аналогічно, у випадку запиту до IP Pod, якщо pod має waypoint, запит буде надісланий до його waypoint для застосування політик L7 до трафіку. Оскільки можливе варіювання міток, пов’язаних із podʼами в Deployment, технічно можливо, що деякі podʼи використовують waypoint, а інші — ні. Користувачам зазвичай рекомендується уникати цього розширеного випадку використання.

Вхідний трафік

Коли pod у mesh ambient отримує вхідний запит, він буде прозоро перенаправлений до локального на вузлі ztunnel. Коли ztunnel отримує запит, він застосовує політики авторизації та пересилає запит лише в разі, якщо запит проходить ці перевірки.

Pod може отримувати трафік HBONE або незашифрований трафік. Стандартно обидва будуть прийняті ztunnel. Запити з джерел поза mesh не матимуть жодної ідентичності учасника при оцінці політик авторизації, користувач може встановити політику, яка вимагатиме ідентичність (будь-яку або конкретну), щоб заблокувати весь незашифрований трафік.

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

Деталі панелі даних

Ідентичність

Весь вхідний та вихідний L4 TCP трафік між навантаженнями в ambient mesh захищений панеллю даних, використовуючи mTLS через HBONE, ztunnel і сертифікати x509.

Як передбачено mTLS, джерело та призначення повинні мати унікальні ідентичності x509, і ці ідентичності повинні використовуватися для встановлення зашифрованого каналу для цього зʼєднання.

Це вимагає від ztunnel керувати кількома різними сертифікатами навантаження, від імені навантажень, що обробляються проксі — один для кожної унікальної ідентичності (службовий обліковий запис) для кожного podʼа вузла. Ідентичність самого ztunnel ніколи не використовується для з’єднань mTLS між навантаженнями.

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

Це застосування CA здійснюється CA Istio за допомогою JWT токена службового облікового запису Kubernetes, який кодує інформацію про pod. Це також є вимогою для будь-яких альтернативних CA, що інтегруються з ztunnel.

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

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

Телеметрія

Ztunnel надає повний набір Стандартних TCP метрик Istio.

Приклад панелі даних для трафіку Layer 4

L4 панель даних ambient зображена на наступній схемі.

На схемі показано кілька навантажень, доданих до ambient mesh, які працюють на вузлах W1 і W2 кластера Kubernetes. На кожному вузлі є один екземпляр проксі ztunnel. У цьому сценарії клієнтські podʼи C1, C2 і C3 потребують доступу до сервісу, що надається подом S1. Немає потреби в розширених функціях L7, таких як маршрутизація трафіку L7 або управління трафіком L7, тому L4 панель даних достатня для отримання mTLS та застосування політик L4 — проксі waypoint не потрібен.

Схема показує, що podʼи C1 і C2, які працюють на вузлі W1, підключаються до podʼа S1, що працює на вузлі W2.

TCP трафік для C1 і C2 захищено тунелюванням через створені ztunnel HBONE зʼєднання. Mutual TLS (mTLS) використовується для шифрування, а також для взаємної автентифікації тунельованого трафіку. SPIFFE ідентичності використовуються для ідентифікації навантажень з обох сторін зʼєднання. Для отримання додаткових відомостей про протокол тунелювання та механізм перенаправлення трафіку зверніться до посібників на HBONE та перенаправлення трафіку ztunnel.

Зверніть увагу, що локальний трафік — показаний на схемі від podʼа C3 до podʼа призначення S1 на вузлі W2 — також проходить через локальний екземпляр проксі ztunnel, тому функції управління трафіком L4, такі як авторизація L4 та телеметрія L4, будуть застосовані однаково до трафіку, незалежно від того, чи перетинає він межі вузлів.

Маршрутизація в mesh з увімкненим waypoint

Waypoint Istio отримує виключно трафік HBONE. Після отримання запиту waypoint перевіряє, чи трафік призначений для Pod або Service, що використовує його.

Прийнявши трафік, waypoint застосовує політики L7 (такі як AuthorizationPolicy, RequestAuthentication, WasmPlugin, Telemetry тощо) перед пересиланням.

Для прямих запитів до Pod запити просто пересилаються безпосередньо після застосування політики.

Для запитів до Service waypoint також застосовує маршрутизацію та балансування навантаження. Стандартно, Service просто маршрутизує до себе, виконуючи балансування навантаження L7 серед своїх точок доступу. Це можна перевизначити за допомогою маршрутів для цього Service.

Наприклад, наступна політика забезпечить, що запити до сервісу echo будуть переслані до echo-v1:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: echo
  rules:
  - backendRefs:
    - name: echo-v1
      port: 80

Наступний рисунок показує шлях даних між ztunnel і waypoint, якщо один налаштований для застосування політик L7. Тут ztunnel використовує тунелювання HBONE для надсилання трафіку до проксі waypoint для обробки L7. Після обробки waypoint надсилає трафік через другий тунель HBONE до ztunnel на вузлі, що хостить обраний сервіс призначення podʼа. Загалом, проксі waypoint може бути розташований на тих самих вузлах, що й pod джерела або призначення, або на інших.