Розуміння налаштувань TLS

4 хвилин(и)

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

Sidecars

Трафік sidecar має різноманітні повʼязані зʼєднання.Розглянемо їх одне за одним.

Зовнішній вхідний трафік Це трафік, що надходить від зовнішнього клієнта і перехоплюється sidecar. Якщо клієнт знаходиться всередині mesh, цей трафік може бути зашифрований за допомогою Istio mutual TLS. Стандартно sidecar налаштований приймати як трафік з mTLS, так і без нього, відомий як режим PERMISSIVE. Режим можна також налаштувати на STRICT, коли трафік повинен бути mTLS, або на DISABLE, коли трафік повинен бути незашифрованим. Режим mTLS налаштовується за допомогою ресурсу PeerAuthentication.
Локальний вхідний трафік Це трафік, який йде до вашого сервісу застосунку від sidecar. Цей трафік завжди передаватиметься без змін. Однак це не означає, що він завжди незашифрований; sidecar може пропустити TLS-зʼєднання. Це лише означає, що нове TLS-зʼєднання ніколи не ініціюється з sidecar.
Локальний вихідний трафік Це вихідний трафік від вашого сервісу застосунку, який перехоплюється sidecar. Ваш застосунок може надсилати незашифрований або TLS-трафік. Якщо увімкнено автоматичний вибір протоколу, Istio автоматично визначить протокол. В іншому випадку вам слід використовувати імʼя порту в сервісі призначення для ручного зазначення протоколу.
Зовнішній вихідний трафік Це трафік, що виходить із sidecar до зовнішнього призначення. Трафік може передаватися без змін або може бути ініційовано TLS-зʼєднання (mTLS або стандартний TLS). Це контролюється за допомогою налаштування режиму TLS у trafficPolicy ресурсу DestinationRule. Налаштування режиму DISABLE передаватиме незашифрований трафік, тоді як SIMPLE, MUTUAL і ISTIO_MUTUAL ініціюватимуть TLS-зʼєднання.

Основні висновки:

PeerAuthentication використовується для налаштування того, який тип mTLS-трафіку sidecar буде приймати.
DestinationRule використовується для налаштування того, який тип TLS-трафіку sidecar буде надсилати.
Імена портів або автоматичний вибір протоколу визначають, який протокол sidecar буде використовувати для розбору трафіку.

Auto mTLS

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

Istio спрощує це за допомогою функції з назвою “Auto mTLS”. Auto mTLS робить саме це. Якщо параметри TLS не налаштовані явно у DestinationRule, sidecar автоматично визначить, чи потрібно надсилати Istio mutual TLS. Це означає, що без будь-якої конфігурації весь трафік всередині mesh буде зашифрований за допомогою mTLS.

Gateways

Будь-який запит до gateway матиме два зʼєднання.

Вхідний запит, ініційований клієнтом, таким як curl або вебоглядачем. Це часто називають “downstream” (низхідним) зʼєднанням.
Вихідний запит, ініційований gateway до якогось бекенду. Це часто називають “upstream” (висхідним) зʼєднанням.

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

Зверніть увагу, що конфігурація ingress і egress gateway однакова.istio-ingress-gateway і istio-egress-gateway — це лише два спеціалізовані deployments gateway. Різниця в тому, що клієнт ingress gateway працює поза межами mesh, тоді як у випадку egress gateway, призначення знаходиться поза mesh.

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

Як частина вхідного запиту, gateway повинен декодувати трафік, щоб застосувати правила маршрутизації. Це робиться на основі конфігурації сервера в ресурсі Gateway. Наприклад, якщо вхідне зʼєднання є незашифрованим HTTP, протокол порту налаштований як HTTP:

apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP

Аналогічно, для необробленого TCP-трафіку протокол буде налаштований як TCP.

Для TLS-зʼєднань є кілька додаткових варіантів:

Який протокол інкапсульовано? Якщо зʼєднання є HTTPS, протокол сервера слід налаштувати як HTTPS. В іншому випадку, для необробленого TCP-зʼєднання, інкапсульованого через TLS, протокол потрібно налаштувати як TLS.
TLS-зʼєднання завершується чи передається далі? Для трафіку з передачею налаштуйте поле режиму TLS на PASSTHROUGH:
```
apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
```
У цьому режимі Istio буде маршрутизувати на основі інформації SNI та передаватиме зʼєднання без змін до призначення.
Чи слід використовувати mutual TLS? Mutual TLS можна налаштувати за допомогою TLS-режиму MUTUAL. Коли це налаштовано, клієнтський сертифікат буде запитано та перевірено на основі налаштованих caCertificates або credentialName:
```
apiVersion: networking.istio.io/v1
kind: Gateway
...
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: MUTUAL
      caCertificates: ...
```

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

Хоча вхідна сторона налаштовує, який тип трафіку слід очікувати та як його обробляти, вихідна конфігурація контролює, який тип трафіку gateway буде надсилати. Це налаштовується за допомогою TLS-налаштувань у ресурсі DestinationRule, як і для зовнішнього вихідного трафіку від sidecars, або автоматично стандартно через auto mTLS.

Єдина різниця полягає в тому, що слід звертати увагу на налаштування Gateway під час конфігурації цього процесу. Наприклад, якщо Gateway налаштований на TLS PASSTHROUGH, а DestinationRule налаштовує створення TLS, у вас виникне подвійне шифрування. Це працює, але часто не є бажаною поведінкою.

Також слід бути обережним з привʼязкою VirtualService до gateway, щоб переконатися, що конфігурація узгоджується з визначенням Gateway.