Кратко

  • Kubernetes описывает NetworkPolicy как желаемое поведение для выбранных Pod. Правила ingress и egress аддитивны; соединение между Pod требует разрешения egress у источника и ingress у назначения.
  • Документация также ограничивает вывод: без реализующего сетевого контроллера объект не даёт эффекта; обработка происходит со временем, но API не показывает когда; влияние на существующие соединения определяется реализацией.
  • Для утверждения о конкретном потоке нужны отдельные записи о ревизии политики, состоянии selector и endpoint, сетевой реализации, наблюдении соединения с границей по времени и самостоятельном решении об идентичности или приложении.

Фраза «default deny» легко заставляет принять YAML за уже состоявшийся результат безопасности. Это неверно. Ценность NetworkPolicy в декларативной поверхности управления: она может изолировать выбранные Pod по ingress, egress или обоим направлениям и описать соединения, которые должны остаться разрешёнными. Это решение о желаемой сетевой границе. Оно не доказывает, что конкретное соединение было отклонено, разрешённое соединение установилось или workload стал безопасным.

Модель ресурса проводит первую границу. NetworkPolicySpec представляет желаемое поведение. Политика выбирает Pod, объявляет изоляцию Ingress или Egress и содержит правила. Эффекты не являются упорядоченными заменами; они складываются. Когда Pod изолирован в направлении, разрешённое множество — объединение того, что допускают все применимые политики. Чтобы Pod-источник достиг Pod-назначения, разрешение должны дать egress источника и ingress назначения. Это правило объясняет набор политик, но не сообщает наблюдённый адрес, порт, протокол, время, процесс, путь пакета или результат соединения.

Состояние selector — отдельный факт. podSelector, namespaceSelector и ipBlock не являются постоянным списком конкретных endpoint. Labels меняются, Pod заменяются, а маршрутизация Service способна изменить путь. Kubernetes предупреждает и о том, что ingress- или egress-механизмы могут переписывать адреса. В таком случае не определено, происходит ли переписывание до или после обработки NetworkPolicy; поведение может различаться в зависимости от сетевого plugin, облачного провайдера, реализации Service или их сочетания. Manifest способен описать ожидаемый охват, но не вынести решение о том, как наблюдённый пакет был представлен в точке применения.

Слой реализации — другая поверхность доказательств. Kubernetes указывает, что NetworkPolicy реализуется сетевым plugin. Если создать ресурс без реализующего его controller, эффекта не будет, хотя API останется доступным. Это не обвинение продукта или администратора. Принятый API-сервером объект доказывает только приём в control plane, а не способность, конфигурацию, здоровье или активность компонента data plane.

Время ещё сильнее сужает вывод. Kubernetes говорит, что созданная NetworkPolicy будет обработана сетевым plugin в итоге, но API не показывает точный момент. Документация описывает и слегка несогласованные представления во время изменения Pod или политик. Если изменение затрагивает существующее соединение, его эффект определяется реализацией. Это не оговорки, а причины не требовать от снимка конфигурации рассказа об исполнении, которого он не хранит.

У протокольной области есть собственный предел. NetworkPolicy определена для соединений TCP, UDP и опционально SCTP четвёртого уровня. Для других протоколов поведение может отличаться между plugins. Видимую границу нельзя превращать в универсальное утверждение о каждом пакете, каждом пути hostNetwork, каждом service mesh, шифровании, идентичности workload, аутентификации, DNS, авторизации приложения или доставке. Для каждой поверхности нужны свои доказательства.

Daniel Kade предлагает пятичастный receipt потока для важных случаев. Первая часть — ревизия политики: namespace, идентичность объекта, generation или неизменяемый снимок, selector, направление, правила и время наблюдения. Вторая — состояние selector и endpoint: labels соответствующих Pod и Namespace, привязка IP или endpoint и момент чтения. Третья — сетевая реализация: заявленная способность NetworkPolicy, версия, относящаяся конфигурация и свидетельство здоровья. Четвёртая — ограниченное временем наблюдение соединения: источник и назначение как наблюдались, протокол, порт, направление, результат, сборщик и пределы видимости.

Пятая — отдельная запись об идентичности workload, авторизации, TLS, DNS, ответе приложения или deployment. Чувствительные детали можно защищать, не смешивая записи.

Этот метод честно описывает и обычные результаты. Правильная политика может соседствовать с независимой неисправностью data plane, мешающей соединению. Поток, разрешённый в обоих направлениях, может провалиться на DNS, TLS, аутентификации или приложении. Политика может быть принята API до того, как конкретный plugin сделает её действенной. Ничто из этого не доказывает дефект или инцидент. Это лишь показывает, почему один manifest не должен нести всю историю сетевого потока.

Источники

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Справочник Kubernetes API — NetworkPolicy v1