Налаштування топології мережі шлюзу

 6 хвилин(и)     перевірка сторінки

Перенаправлення атрибутів зовнішнього клієнта (IP-адреса, інформація про сертифікат) до цільових навантажень

Багато застосунків потребують знання IP-адреси клієнта та інформації про сертифікат для коректної роботи. Видатними прикладами є інструменти для журналювання та аудиту, які потребують заповнення IP-адреси клієнта, та засоби безпеки, такі як WAF (брандмауери вебзастосунків), яким потрібна ця інформація для правильного застосування правил. Здатність надавати атрибути клієнта сервісам давно стала основою зворотних проксі. Для передачі цих атрибутів клієнта до цільових навантажень проксі використовують заголовки X-Forwarded-For (XFF) та X-Forwarded-Client-Cert (XFCC).

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

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

Детальніше про X-Forwarded-For дивіться у RFC від IETF.

Налаштування топологій мережі

Конфігурацію заголовків XFF та XFCC можна встановити глобально для всіх робочих навантажень шлюзу через MeshConfig або для конкретного шлюзу за допомогою анотації для podʼа. Наприклад, для глобального налаштування під час встановлення або оновлення з використанням ресурсу IstioOperator:

spec:
  meshConfig:
    defaultConfig:
      gatewayTopology:
        numTrustedProxies: <VALUE>
        forwardClientCertDetails: <ENUM_VALUE>

Також можна налаштувати ці параметри, додавши анотацію proxy.istio.io/config до специфікації podʼа вашого шлюзу Istio:

...
  metadata:
    annotations:
      "proxy.istio.io/config": '{"gatewayTopology" : { "numTrustedProxies": <VALUE>, "forwardClientCertDetails": <ENUM_VALUE> } }'

Налаштування заголовків X-Forwarded-For

Застосунки покладаються на зворотні проксі для передачі атрибутів клієнта в запиті, таких як заголовок X-Forward-For. Однак через різноманітність топологій мереж, у яких може бути розгорнуто Istio, потрібно встановити значення numTrustedProxies на кількість надійних проксі, що розміщені перед шлюзом Istio, щоб правильно витягти IP-адресу клієнта. Це керує значенням, яке заповнюється шлюзом для вхідного трафіку в заголовку X-Envoy-External-Address, яке може надійно використовуватися сервісами для доступу до оригінальної IP-адреси клієнта.

Наприклад, якщо у вас є хмарний балансувальник навантаження та зворотний проксі перед вашим шлюзом Istio, встановіть numTrustedProxies на значення 2.

Приклад використання можливості X-Forwarded-For з httpbin

  1. Виконайте наступну команду, щоб створити файл з назвою topology.yaml, де параметр numTrustedProxies встановлено на 2, та встановіть Istio:

    $ cat <<EOF > topology.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      gatewayTopology:
        numTrustedProxies: 2
EOF
$ istioctl install -f topology.yaml

  2. Створіть простір імен httpbin:

    $ kubectl create namespace httpbin
namespace/httpbin created

  3. Встановіть мітку istio-injection зі значенням enabled для інʼєкції sidecar:

    $ kubectl label --overwrite namespace httpbin istio-injection=enabled
namespace/httpbin labeled

  4. Розгорніть httpbin у просторі імен httpbin:

    Zip
    $ kubectl apply -n httpbin -f @samples/httpbin/httpbin.yaml@

  5. Розгорніть шлюз, повʼязаний з httpbin:

Zip
$ kubectl apply -n httpbin -f @samples/httpbin/httpbin-gateway.yaml@
  1. Встановіть локальну змінну середовища GATEWAY_URL на основі IP-адреси шлюзу для вхідного трафіку Istio:
$ export GATEWAY_URL=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

  1. Виконайте наступну команду curl, щоб імітувати запит із проксі-адресами в заголовку X-Forwarded-For:

    $ curl -s -H 'X-Forwarded-For: 56.5.6.7, 72.9.5.6, 98.1.2.3' "$GATEWAY_URL/get?show_env=true" | jq '.headers["X-Forwarded-For"][0]'
  "56.5.6.7, 72.9.5.6, 98.1.2.3,10.244.0.1"

Наведений вище результат показує заголовки запиту, які отримало навантаження httpbin. Коли шлюз Istio отримав цей запит, він встановив заголовок X-Envoy-External-Address на передостанню адресу (numTrustedProxies: 2) у заголовку X-Forwarded-For з вашої команди curl. Крім того, шлюз додає свою IP-адресу до заголовка X-Forwarded-For, перш ніж передати його до навантаження httpbin.

Налаштування заголовків X-Forwarded-Client-Cert

Згідно з документацією Envoy щодо XFCC:

Щоб налаштувати, як обробляються заголовки XFCC, встановіть forwardClientCertDetails у вашому IstioOperator:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      gatewayTopology:
        forwardClientCertDetails: <ENUM_VALUE>

де ENUM_VALUE може мати одне з наступних значень:

ENUM_VALUEОпис
UNDEFINEDПоле не задано.
SANITIZEНе надсилати заголовок XFCC на наступний хоп.
FORWARD_ONLYЯкщо зʼєднання з клієнтом є mTLS (взаємний TLS), переслати заголовок XFCC у запиті.
APPEND_FORWARDЯкщо зʼєднання з клієнтом є mTLS, додати інформацію про сертифікат клієнта до заголовка XFCC і переслати його.
SANITIZE_SETЯкщо зʼєднання з клієнтом є mTLS, скинути заголовок XFCC з інформацією про сертифікат клієнта та надіслати його на наступний хоп. Це стандартне значення для шлюзу.
ALWAYS_FORWARD_ONLYЗавжди пересилати заголовок XFCC у запиті, незалежно від того, чи є зʼєднання з клієнтом mTLS.

Детальніше дивіться в документації Envoy для прикладів використання цієї можливості.

Протокол PROXY

Протокол PROXY дозволяє обмінюватися та зберігати атрибути клієнта між TCP-проксі без використання протоколів L7, таких як HTTP, і заголовків X-Forwarded-For та X-Envoy-External-Address. Він призначений для сценаріїв, де зовнішній TCP-балансувальник навантаження потребує проксіювати TCP-трафік через шлюз Istio до бекенду TCP-сервісу та все ще надавати атрибути клієнта, такі як IP-адреса джерела, до точок доступу TCP-сервісу.

Протокол PROXY можна ввімкнути за допомогою EnvoyFilter.

Якщо ваш зовнішній TCP-балансувальник налаштований на пересилання TCP-трафіку та використання протоколу PROXY, слухач TCP на шлюзі Istio також має бути налаштований на приймання протоколу PROXY. Щоб увімкнути протокол PROXY на всіх TCP-слухачах на шлюзах, встановіть proxyProtocol у вашому IstioOperator. Наприклад:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      gatewayTopology:
        proxyProtocol: {}

Альтернативно, розгорніть шлюз із наступною анотацією podʼа:

metadata:
  annotations:
    "proxy.istio.io/config": '{"gatewayTopology" : { "proxyProtocol": {} }}'

IP-адреса клієнта отримується з протоколу PROXY шлюзом і встановлюється (або додається) в заголовки X-Forwarded-For і X-Envoy-External-Address. Зверніть увагу, що протокол PROXY є взаємовиключним з заголовками L7, такими як X-Forwarded-For та X-Envoy-External-Address. Якщо протокол PROXY використовується разом із конфігурацією gatewayTopology, перевага надається numTrustedProxies та отриманому заголовку X-Forwarded-For для визначення довірених адрес клієнтів, а інформація про клієнта протоколу PROXY буде ігнорована.

Зазначте, що наведений приклад лише налаштовує шлюз для приймання вхідного TCP-трафіку з протоколом PROXY — для налаштування Envoy на використання протоколу PROXY при взаємодії з upstream-сервісами дивіться документацію Envoy.

Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!