Чекну тоже по rules. Задача закрыть определённый путь в урле

салют всем, никто не сталкивался с некорректным мержом VS в енвой конфиг при использовании нескольких доменов в VS ?

не работает так.......
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: dev
spec:
 selector:
   matchLabels:
     app: httpbin-app
 action: ALLOW
 rules:
   - from:
       - source:
           ipBlocks: ["<IP_ADDRESS>"]
     to:
       - operation:
           hosts: ["<PUBLIC_HOST>"]
           paths: ["/httpbin*"]

Сделал так, но он блокирует все что есть в истио...
kind: AuthorizationPolicy
metadata:
 name: httpbin-access
 namespace: istio-system
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
 action: ALLOW
 rules:
   - from:
       - source:
           ipBlocks: ["<IP_ADDR>"]
     to:
       - operation:
           hosts: ["<PUBLIC_HOST>"]
           paths: ["/httpbin*"]

отсюда вопрос, может ли истио блокировать доступ на определенные пути?

Мы сделали роуты в несуществующие сервисы😁

Всем привет. Нужна помощь, мб кто сталкивался с таким.
Хочу подключиться к сервису внутри k8s кластера со своей локали.
Когда нет AuthorizationPolicy(далее AP) то это работает (пробовал с istio 1.9.8 и 1.10.3).

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: auth-admin
 namespace: istio-system
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
 action: ALLOW
 rules:
   - to:
     - operation:
         hosts:
         - ["<host>"]
         paths:
         - ["<paths>"]
   - from:
     - source:
         requestPrincipals:
         -  ["<requestPrincipals>"]
     to:
     - operation:
         hosts:
         - ["<host>"]
         notPaths:
        - ["<notPaths>"]
     
Когда добавляю AP то получаю 403 ошибку и "cors missing allow origin".
Добавил хедеры в VS:
headers:
         response:
           set:
             access-control-allow-credentials: "true"
             access-control-allow-headers: Content-Type, Authorization, Access-Control-Allow-Headers, X-Requested-With
             access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
             access-control-allow-origin: "*"
             access-control-max-age: "86400"

В итоге получаю 403 и "cors preflight did not succeed"

есть же отдельная политика для cors
https://istio.io/v1.4/docs/reference/config/networking/virtual-service/#CorsPolicy

Пробовал. Не работает.

Поэтому просто добавил хидеры.

кто нибудь может рассказать как именно istio-ingressgateway использует папку /etc/istio/pod внутри контейнера  монтируемую туда кубами? Кубы монтируют туда cpu-limit cpu-request и подобные вещи. но я не понимаю как  именно  ее использует локальный  envoy запускаемый внутри пода.  Не могу  найти отсылок в конфиге или еще где до этой папки

Привет народ!
А у кого-нибудь тут был опыт использования sidecars + consul-agent в поде? Не могу понять, но STRICT мод (форсирования mTLS между подами) ломает коммуникацию между агентами

Префлайт реквест к чему? Может у тебя там HEAD какой, а ты его не указал

пропиши корс полиси просто, префлайт это какраз таки OPTIONS запрос что бы узнать разрешенные методы, хотя у тя опшнс запрос разрешен

corsPolicy сделай прост в virtualService-e
тебе нужно ориджин определенный разрешить

в истио кстати круто вопрос с корсами решается, в любой компании на любом бекенде хоть раз была проблема с корсами, где с nginx-ом нужно голову сломать, а в Istio это за 1 минуту решается)

Корсы почему то не работают, я уже прописывал, в итоге ориджин через хидеры разрешил.

Но проблема с preflight осталась.

Всем привет! нужна консультация, можно ли и если можно то как сделать fault injection не трогая существующие vs? будет ли это работать если добавить новый vs с fault injection на ingress? Дело в том, что нам нужно сделать delay, к примеру 200 ms  на работающем приложении для деструктивных тестов

хочется попробовать реализовать вот такую штуку https://istio.io/latest/docs/tasks/traffic-management/fault-injection/
при этом не трогать существующие  virtual service

На сколько я помню, для одного хоста применяется только один VS. Но могу ошибаться

Нет, главное чтоб правила роутинга не пересекались