Для платформы из нескольких десятков микросервисов обсуждается переход от сетевой сегментации на уровне Kubernetes NetworkPolicy к service mesh с mTLS между всеми сервисами (zero-trust). Спроектируйте решение и обсудите, при каких условиях этот переход оправдан, а при каких избыточен?

Короткий ответ

Явного единственно верного ответа нет: NetworkPolicy контролирует, какие пары Pod/namespace могут обмениваться трафиком на уровне L3/L4, но не даёт криптографической аутентификации и шифрования самого трафика между сервисами; service mesh с mTLS добавляет именно это, но вносит дополнительную операционную сложность (sidecar, управление сертификатами, отладка), которая оправдана не для каждой платформы.

Как это работает подробнее

NetworkPolicy — это decision на уровне сети (IP/порт/namespace/label), реализуемый CNI; она не проверяет, что трафик действительно пришёл от ожидаемого сервиса, а не от скомпрометированного Pod с подменённым IP в разрешённом диапазоне. Service mesh (Istio, Linkerd) внедряет sidecar-прокси в каждый Pod, который устанавливает mTLS-соединение на основе криптографической идентичности сервиса (а не IP), и может дополнительно применять L7-политики (по HTTP-методам, путям).

Сравнение

• Компромисс. service mesh даёт сильную криптографическую изоляцию и детальную L7-видимость/контроль, но стоит дополнительных CPU/памяти на каждый Pod, усложняет troubleshooting и требует команды, способной поддерживать control plane mesh; NetworkPolicy проще и дешевле в эксплуатации, но ограничивается L3/L4 без аутентификации идентичности. Критерий выбора — реальные требования compliance/аудита к шифрованию in-transit, масштаб платформы и наличие ресурсов на поддержку mesh; решение нужно принимать по конкретным требованиям, а не по общей репутации технологии.

Пример кода

security-example-467.yamlКопировать

# Istio PeerAuthentication: принудительный strict mTLS для namespace prod
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: prod
spec:
  mtls:
    mode: STRICT

Что использовать на практике

• Практика. переход на mesh обычно оправдан, когда число сервисов и команд велико, требования к аудиту/compliance требуют шифрования трафика между всеми внутренними сервисами, или нужна детальная L7-авторизация; для платформы из нескольких сервисов с одной командой и умеренными требованиями overhead sidecar'ов (ресурсы, латентность, сложность отладки сетевых проблем) может не оправдывать выигрыш по сравнению с NetworkPolicy и TLS, настроенным на уровне приложения вручную.
• Проверка. Ожидаемое поведение: после применения политики любой plaintext-запрос (без mTLS) к сервисам в namespace prod будет отклонён на уровне sidecar-прокси; это проверяется попыткой обратиться к сервису напрямую, минуя mesh (например, запрос без клиентского сертификата из Pod без sidecar), и наблюдением отказа соединения — тогда как легитимный трафик между сервисами с sidecar продолжает работать прозрачно для приложения.

Подводные камни

• Ошибка. внедрять service mesh «потому что это современная практика» без чёткого требования, которое NetworkPolicy не покрывает; включать mTLS в mesh, но не применять strict-режим, оставляя возможность plaintext-соединений как fallback; не закладывать ресурсы и экспертизу на отладку дополнительного сетевого слоя (sidecar добавляет точки отказа и усложняет трассировку проблем).