Видимість ServiceEntry

ServiceEntry додає сервіс до внутрішнього реєстру сервісів Istio. Зазвичай, ServiceEntry видимий для кожного робочого навантаження в mesh: будь-хто, хто може створити ServiceEntry в будь-якому просторі імен, може визначити будь-яку назву хоста, наприклад example.com, і вплинути на те, як весь mesh визначає та маршрутизує до нього.

Поле exportTo не захищає від цього, оскільки воно оголошується самим автором ServiceEntry: воно дозволяє власнику сервісу визначати область дії того, що він публікує, але не встановлює жорстких обмежень. Раніше адміністратору мережі потрібно було обмежувати створення ServiceEntry за допомогою зовнішнього контролю доступу, такого як ValidatingAdmissionPolicy у Kubernetes або веб-хук.

Починаючи з Istio 1.31, налаштування mesh serviceEntryVisibility дає адміністратору mesh цей контроль з одного місця. ambient data plane (ztunnel та waypoints) враховує видимість, коли вона налаштована; sidecars та gateways можуть підключитися. Функція є інертною, якщо не налаштована: якщо serviceEntryVisibility не встановлено, нічого не змінюється.

Ця конструкція навмисно відтворює звичний шаблон Kubernetes: RoleBinding діє лише в межах власного простору імен, тоді як створення ефекту на рівні всього кластера за допомогою ClusterRoleBinding зарезервовано для адміністраторів кластера. serviceEntryVisibility дозволяє адміністратору мережі застосовувати ту саму модель до ServiceEntry: встановивши defaultVisibility: NAMESPACE, адміністратор змушує кожен ServiceEntry поводитися як будь-який інший ресурс у межах простору імен, а видимість за межами власного простору імен ServiceEntry стає можливістю, яку адміністратор надає явно.

Як визначається видимість

Коли serviceEntryVisibility налаштовано, istiod визначає видимість для кожного ServiceEntry:

1. Список policies оцінюється по черзі. Перша політика, чиї matchingRules всі відповідають (AND семантика), визначає видимість.
2. Якщо жодна політика не відповідає, застосовується defaultVisibility.

Сьогодні єдине правило відповідності — namespaceSelector: стандартний Kubernetes label selector, що оцінюється проти міток простору імен, в якому визначено ServiceEntry.

ServiceEntry вирішується до однієї з трьох видимостей:

Див. довідник конфігурації mesh для повної документації полів.

Налаштування видимості

Наступна конфігурація тримає кожен ServiceEntry приватним у власному просторі імен, дозволяючи ресурсам ServiceEntry в istio-system, просторі імен, до якого має доступ лише адміністратор mesh, бути публікованими у всьому mesh:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    serviceEntryVisibility:
      # ServiceEntries, що не відповідають жодній політиці нижче, залишаються в своєму просторі імен.
      defaultVisibility: NAMESPACE
      policies:
        # ServiceEntries в istio-system видимі mesh-wide.
        - visibility: PUBLIC
          matchingRules:
            - namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: istio-system

Політики також можуть надавати видимість групам просторів імен. Наприклад, політика, що відповідає мітці простору імен trusted: "true", дозволяє делегувати здатність публікувати mesh-wide ServiceEntry ресурси шляхом позначення просторів імен.

Видимість у режимі ambient

Коли serviceEntryVisibility налаштовано, ambient data plane завжди враховує її. Istiod визначає видимість кожного ServiceEntry та розподіляє її з визначенням сервісу; ztunnel потім застосовує її на стороні клієнта, на основі простору імен робочого навантаження, що робить запит:

• PUBLIC сервіс поводиться саме як раніше.
• NAMESPACE сервіс може бути виявлений та визначений робочими навантаженнями у власному просторі імен. Для робочих навантажень у кожному іншому просторі імен, це так, ніби ServiceEntry ніколи не існував.
• NONE сервіс ніколи не доставляється до жодного data plane.

Приховане означає відсутнє, а не заблоковане

Це зроблено навмисно: якби ztunnel, навпаки, відхиляв DNS-запити щодо прихованих імен хостів, то ServiceEntry, що заявляє про example.com в одному просторі імен, призвів би до порушення роботи example.com у всій мережі — саме цю проблему й покликана вирішувати ця функція. Конкретно, для клієнта, що знаходиться поза простором імен ServiceEntry:

• DNS: запит для прихованого хостнейму перенаправляється до upstream резолвера, повертаючи реальну відповідь (або реальний NXDOMAIN, якщо назва не існує публічно).
• Адреси: трафік до IP адреси, яку претендує лише прихований ServiceEntry, обробляється як невідомий трафік і пропускається до його оригінального призначення.
• Спільні хостнейми: якщо прихований ServiceEntry та PUBLIC визначають однакову назву хоста, клієнти поза простором імен прихованого запису завжди обслуговуються PUBLIC визначенням.

Waypoints

Привʼязка waypoint з іншого простору імен до NAMESPACE-видимості ServiceEntry дозволила б трафіку та конфігурації вийти за межі простору імен, тому control plane відмовляє в cross-namespace waypoint привʼязках для них. Відмова повідомляється в статусі ServiceEntry з умовою istio.io/WaypointBound: False та причиною CrossNamespaceWaypointForbidden.

Привʼязка waypoint в тому самому просторі імен працює нормально, а ресурси PUBLIC ServiceEntry не зазнають впливу.

Розширення видимості на sidecars та gateways

У sidecar режимі, власники сервісів вже обмежують свої ресурси ServiceEntry за допомогою exportTo, тому врахування видимості є opt-in для sidecars, дозволяючи інкрементальне прийняття під час ambient міграції без зміни робочого sidecar розгортання:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    serviceEntryVisibility:
      defaultVisibility: NAMESPACE
      applyToSidecars: true

З увімкненим applyToSidecars, визначена видимість діє як потолок на exportTo ServiceEntry: ефективна область — це перетин оголошеного exportTo та отриманої видимості. Незважаючи на назву поля, це застосовується до всіх Envoy-базових проксі, включаючи ingress та egress gateways.

Видимість може звужувати те, що оголошує exportTo, але ніколи не розширює його. У режимі sidecar, exportTo є механізмом scoping конфігурації, що контролює, скільки конфігурації istiod надсилає до кожного проксі. Розширення його для відповідності ширшій видимості відправило б конфігурацію ServiceEntry назад у проксі, які його власник навмисно виключив з scoping. Видимість є тому лише обмеженням: ServiceEntry з exportTo вузьшим за свою видимість зберігає свою вузьшу область.

Перевірка видимості

Коли serviceEntryVisibility налаштовано, istiod повідомляє видимість, яку отримав data plane, як умову статусу ServiceEntry типу istio.io/VisibilityApplied, з причиною, що вказує на застосовану видимість:

$ kubectl get serviceentry my-service -n team-a -o jsonpath='{.status.conditions[?(@.type=="istio.io/VisibilityApplied")].reason}'
Namespace

Статус стану завжди True; поле reason несе визначену видимість (Public або Namespace). Коли serviceEntryVisibility не налаштовано, умова не записується.

Ви також можете перевірити видимість, яку ztunnel застосовує для кожного сервісу, про який він знає. JSON та YAML виводи istioctl ztunnel-config service включають поле visibility:

$ istioctl ztunnel-config service --service-namespace team-a -o yaml

Kubernetes Serviceи завжди повідомляють Public; ServiceEntry-backed сервіси повідомляють свою визначену видимість. Крім того, ztunnel логує на рівні debug щоразу, коли він приховує сервіс від клієнта під час резолвингу.

Що видимість НЕ робить

• Видимість не є авторизацією. Видимість контролює, чи клієнт може виявити та визначити сервіс; вона не вирішує, чи дозволений вхідний запит. Використовуйте AuthorizationPolicy для контролю того, які клієнти можуть отримати доступ до робочого навантаження — див. Layer 4 security policy.
• Видимість не є секретністю. Зменшення видимості ServiceEntry регулює, які клієнтські робочі навантаження виконують визначення; вона не приховує існування сервісу. Ресурс залишається читабельним через Kubernetes API відповідно до RBAC, і сервіс все ще зʼявляється в дампах конфігурації data plane, таких як istioctl ztunnel-config service.
• Вона застосовується лише до ServiceEntry. Kubernetes Serviceи завжди видимі mesh-wide в режимі ambient.
• Немає audit або warn-only режиму. Коли налаштовано, видимість завжди набирає чинності.

Дивіться також

• Довідник з конфігурації mesh ServiceEntryVisibility
• Область дії конфігурації — exportTo та Sidecar для режиму sidecar, а також discoverySelectors, які застосовуються в будь-якому режимі площини даних
• Проксі-сервери DNS
• Налаштування проксі-серверів Waypoint