Міграція політик

У режимі ambient, керування трафіком L7 обробляється waypoint проксі замість sidecar проксі. Це змінює те, як політики виражаються та застосовуються:

• VirtualService підтримка з waypoints є Alpha. Хоча це може працювати в окремих випадках, наполегливо рекомендується перейти на використання HTTPRoute. Змішування VirtualService та HTTPRoute для одного робочого навантаження не підтримується і призводить до невизначеної поведінки.
• DestinationRule політики трафіку (налаштування пулу зʼєднань, виявлення викидів, TLS) підтримуються waypoints і не вимагають змін. Проте, HTTPRoute використовує Kubernetes Services як backendRefs для маршрутизації замість підмножин DestinationRule, тому версійне розділення трафіку в HTTPRoute вимагає окремих Services для кожної версії.
• AuthorizationPolicy ресурси, що використовують правила L7 (методи HTTP, шляхи або заголовки), або що використовують action: CUSTOM або action: AUDIT, мають використовувати targetRefs (замість робочого навантаження selector) для привʼязки політики до підтримуваних ресурсів, для отримання додаткової інформації перевірте документацію AuthorizationPolicy.
• RequestAuthentication та WasmPlugin ресурси вимагають waypoint проксі і мають бути цілеспрямовані за допомогою targetRefs для вказівки на waypoint.
• EnvoyFilter ресурси не підтримуються на waypoints. Якщо у вас є ресурси EnvoyFilter, що конфігурують поведінку sidecar проксі, вони будуть мовчки ігноруватися після міграції і мають бути оброблені перед продовженням:
  • Якщо фільтр додає власну функціональність Envoy, оцініть, чи може WasmPlugin забезпечити еквівалентну поведінку на waypoint.
  • Якщо фільтр більше не потрібен, видаліть його.
  • Якщо немає ambient-сумісної альтернативи, це є блокером міграції. Не продовжуйте, доки залежність не буде вирішена.

Аудит ваших наявних політик

Почніть з переліку всіх L7 ресурсів у вашому кластері:

$ kubectl get virtualservice,destinationrule -A

Визначте ресурси AuthorizationPolicy, що знадобляться waypoint (правила L7 або CUSTOM/AUDIT дії):

$ kubectl get authorizationpolicy -A --no-headers | while read ns name rest; do
    if kubectl get authorizationpolicy "$name" -n "$ns" -o yaml | grep -qE "(methods:|paths:|headers:|action: CUSTOM|action: AUDIT)"; then
      echo "$ns/$name"
    fi
  done

Визначте ресурси DestinationRule з підмножинами (вони вимагають версійно-специфічних Services в режимі ambient):

$ kubectl get destinationrule -A --no-headers | while read ns name rest; do
    if kubectl get destinationrule "$name" -n "$ns" -o yaml | grep -q "subsets:"; then
      echo "$ns/$name"
    fi
  done

Міграція VirtualService на HTTPRoute

HTTPRoute є стабільним, підтримуваним API маршрутизації L7 для режиму ambient.

Приклад: Маршрутизація на основі заголовків

Наступний VirtualService маршрутизує запити з end-user: jason на reviews версію 2, а всі інші запити на версію 1, використовуючи підмножини:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Оскільки HTTPRoute не підтримує підмножини DestinationRule, ви маєте спочатку створити версійно-специфічні Services:

apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
  namespace: bookinfo
spec:
  selector:
    app: reviews
    version: v1
  ports:
  - port: 9080
    name: http
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
  namespace: bookinfo
spec:
  selector:
    app: reviews
    version: v2
  ports:
  - port: 9080
    name: http

Потім замініть VirtualService на HTTPRoute, що привʼязується до reviews Service безпосередньо (використовуючи kind: Service як parentRef). Це правильна модель привʼязки для режиму ambient — waypoint використовує Service як анкер маршрутизації:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
  namespace: bookinfo
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews
    port: 9080
  rules:
  - matches:
    - headers:
      - name: end-user
        value: jason
    backendRefs:
    - name: reviews-v2
      port: 9080
  - backendRefs:
    - name: reviews-v1
      port: 9080

Для повного довідника з можливостей HTTPRoute, див. документацію з керування трафіком.

Міграція AuthorizationPolicy для правил L7

У режимі sidecar, ресурси AuthorizationPolicy використовують selector для цілеспрямування на podʼи безпосередньо. У режимі ambient, політики авторизації L7 мають бути застосовані waypoint проксі і тому мають використовувати targetRefs для цілеспрямування на батьківський Service waypoint або сам Gateway.

Політики L4 (змін не потрібно)

L4 ресурси AuthorizationPolicy, що відповідають лише на принципали джерела, простори імен або IP діапазони, працюють в режимі ambient без модифікації. Вони застосовуються ztunnel.

# Ця політика L4 не вимагає змін для режиму ambient
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/bookinfo/sa/productpage"]

Політики L7

Політики, які фільтруються за методами HTTP, шляхами або заголовками, або які використовують action: CUSTOM чи action: AUDIT, повинні бути спрямовані на проксі-сервер Waypoint. Замініть selector на targetRefs, що вказують на Service, який захищає Waypoint, або на сам ресурс Gateway Waypoint:

# До: sidecar-стиль (на основі селектора)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

# Після: ambient-стиль (targetRefs до Service)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: reviews
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

Крім того, ви можете безпосередньо вказати на ресурс waypoint Gateway. У цьому випадку політика застосовуватиметься до всього трафіку, що обробляється цим waypoint, незалежно від Service призначення:

# Після: ambient-стиль (targetRefs до waypoint Gateway)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get-reviews
  namespace: bookinfo
spec:
  targetRefs:
  - kind: Gateway
    group: gateway.networking.k8s.io
    name: waypoint
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

Спрямування на Service є більш точним варіантом і рекомендується, коли політика має застосовуватися до окремого сервісу. Спрямування на Gateway корисне, коли політика має застосовуватися до всіх сервісів у просторі імен.

Запобігання оминання waypoint

Коли waypoint використовується, переконайтеся, що робочі навантаження не можуть бути досягнуті шляхом його оминання. Використовуйте робоче навантаження selector DENY політику, що застосовується ztunnel (на pod призначення). Оскільки ця політика перевіряє лише принципала джерела (атрибут L4), ztunnel може застосувати її коректно.

Визначте, коли застосувати запобігання оминання

Під час поетапної міграції деякі робочі навантаження джерела можуть все ще перебувати в режимі sidecar. Робочі навантаження в режимі sidecar оминають waypoint і підключаються безпосередньо до ztunnel у пункті призначення, тому ztunnel сприймає ідентифікатор sidecar як принципал джерела, а не ідентифікатор waypoint. Політика DENY, що передбачає використання виключно waypoint, відхилить їхній трафік.

Оберіть один з наступних варіантів перед застосуванням політики:

Варіант 1: Відкладіть запобігання оминання, доки всі джерела не будуть мігровані. Не застосовуйте DENY політику, доки кожне робоче навантаження, яке викликає цей сервіс, не перейде в режим ambient. Це простіший підхід, коли ви контролюєте всіх викликачів.

Варіант 2: Дозвольте трафік як від waypoint, так і від sidecar принципалів. Застосуйте політику негайно, але додайте службові облікові записи решти робочих навантажень-sidecar до списку винятків notPrincipals разом із waypoint. Вилучайте кожен принципал sidecar зі списку по мірі його міграції. Коли всі викликачі перейдуть у режим ambient, у списку має залишитися лише принципал waypoint.

Застосуйте політику запобігання омиання

Знайдіть службовий обліковий запис, що використовується вашим waypoint:

$ kubectl get pod -n <namespace> -l gateway.istio.io/managed=istio.io-mesh-controller \
    -o jsonpath='{.items[0].spec.serviceAccountName}'

Для Варіанту 1, застосуйте політику лише після міграції всіх викликачів:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-waypoint-bypass
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals:
        - "cluster.local/ns/bookinfo/sa/waypoint"

Для Варіанту 2, включіть принципалів sidecar у список винятків під час міграції:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-waypoint-bypass
  namespace: bookinfo
spec:
  selector:
    matchLabels:
      app: reviews
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals:
        - "cluster.local/ns/bookinfo/sa/waypoint"
        - "cluster.local/ns/bookinfo/sa/productpage"

Наступні кроки

Перейдіть до Увімкнення режиму ambient для позначення просторів імен, активації waypoints та видалення інʼєкції sidecar.