Керування трафіком, ЧаПи

Правила можна переглянути за допомогою команди kubectl get virtualservice -o yaml

Стандартно Istio захоплює вхідний трафік на всіх портах. Ви можете змінити цю поведінку, використовуючи анотацію traffic.sidecar.istio.io/includeInboundPorts у podʼі, щоб вказати явний список портів для захоплення, або використовуючи traffic.sidecar.istio.io/excludeOutboundPorts для вказівки списку портів, які потрібно пропустити.

Обидва ці налаштування DestinationRule дозволяють передавати трафік з взаємним TLS. За допомогою ISTIO_MUTUAL сертифікати Istio будуть використовуватися автоматично. Для MUTUAL потрібно налаштувати ключ, сертифікат і довірений CA. Це дозволяє ініціювати взаємний TLS з застосунками, які не є частиною Istio.

Так, Istio повністю підтримує ці типи завантажень починаючи з Istio 1.10.

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

Наприклад, наступний ресурс ingress відповідає запитам для хосту example.com з URL /helloworld.

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Однак наступні правила не працюватимуть, оскільки вони використовують регулярні вирази в шляху та анотації ingress.kubernetes.io:

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Анотації Ingress, інші, ніж клас Ingress, не будуть враховані
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Після застосування конфігурації CORS ви можете помітити, що ніби нічого не змінилося, і запитати, що пішло не так. CORS є часто неправильно зрозумілим HTTP-концептом, що часто призводить до плутанини при конфігурації.

Щоб зрозуміти це, корисно зробити крок назад і подивитися на що таке CORS і коли його слід використовувати. Стандартно оглядачі мають обмеження на “кросдоменні” запити, ініційовані скриптами. Це заважає, наприклад, вебсайту attack.example.com здійснити JavaScript-запит до bank.example.com і вкрасти чутливу інформацію користувача.

Щоб дозволити цей запит, bank.example.com має дозволити attack.example.com здійснювати кросдоменні запити. Ось де і зʼявляється CORS. Якби ми обслуговували bank.example.com у кластері з увімкненим Istio, ми могли б налаштувати corsPolicy, щоб дозволити це:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

У цьому випадку ми явно дозволяємо один орієнтир; маски часто використовуються для не чутливих сторінок.

Після цього поширена помилка — це надсилання запиту, наприклад curl bank.example.com -H "Origin: https://attack.example.com", і очікування, що запит буде відхилено. Однак curl і багато інших клієнтів не побачать відхилення запиту, оскільки CORS є обмеженням оглядача. Конфігурація CORS просто додає заголовки Access-Control-* у відповідь; клієнт (оглядач) вирішує відхилити запит, якщо відповідь не є задовільною. В оглядачах це робиться за допомогою Preflight запиту.

Наразі Istio підтримує протоколи на основі TCP. Крім того, Istio надає функціональність, таку як маршрутизація та метрики, для інших протоколів, таких як http та mysql.

Для перегляду списку всіх протоколів та інформації про налаштування протоколів перегляньте документацію з Вибору протоколів.