Чтобы защищать Kubernetes, нужно сначала понять, как в нём вообще передаётся трафик. Без этого NetworkPolicy, service mesh и eBPF превращаются в набор терминов.
Начнём с простой схемы:
Kubernetes cluster
|
+-- node-1
| +-- pod A
| +-- pod B
|
+-- node-2
+-- pod C
+-- pod D
Node — физический сервер или виртуальная машина, на которой запускаются pod. Каждый pod получает сетевое подключение к сети кластера.
Каждый pod — отдельный сетевой endpoint
Базовая модель Kubernetes предполагает, что pod получают собственные IP-адреса:
pod A: 10.244.1.10
pod B: 10.244.1.11
pod C: 10.244.2.20
Если между ними не введены дополнительные ограничения, приложения должны иметь возможность взаимодействовать друг с другом через сеть.
Именно поэтому новая установка Kubernetes не означает автоматически «сегментированную среду».
Что делает CNI
CNI расшифровывается как Container Network Interface.
Частая ошибка — говорить о CNI как о конкретном продукте. На самом деле CNI — спецификация взаимодействия контейнерной среды с сетевыми плагинами.
Конкретный сетевой плагин реализует практические функции: выдаёт pod сетевое подключение, настраивает маршрутизацию, соединяет pod на разных nodes, может применять NetworkPolicy, собирать телеметрию и иногда предоставлять расширенные L7- или DNS-политики.
Поэтому вопрос «есть ли у нас CNI?» почти бессмысленен. Важнее спросить: какой именно сетевой плагин используется и как он реализует datapath?
Что такое datapath
Datapath — реальный путь обработки пакета.
Control plane задаёт желаемое состояние, а datapath непосредственно принимает решение по конкретному пакету: пропустить, изменить маршрут или заблокировать.
В Linux это может быть реализовано через маршрутизацию, iptables/nftables, виртуальные интерфейсы, туннели или eBPF.
Для ИБ это важно, потому что именно datapath определяет, где на самом деле применяется политика.
Underlay и overlay
Underlay — базовая сеть между самими nodes:
node-1: 192.168.100.11
node-2: 192.168.100.12
node-3: 192.168.100.13
Overlay — логическая сеть поверх underlay. Она может позволять pod на разных nodes выглядеть участниками одной логической сети.
Например, при VXLAN:
pod A
|
node-1
|
[VXLAN tunnel]
|
node-2
|
pod C
Но Kubernetes не требует overlay обязательно. Некоторые реализации используют обычную маршрутизацию, BGP или eBPF datapath.
Как работает Service
Pod динамичны. Для стабильного доступа к группе pod используется Service.
Предположим:
backend-1 = 10.244.2.10
backend-2 = 10.244.3.21
backend-3 = 10.244.1.37
Создаётся Service:
backend.default.svc.cluster.local
Приложение обращается к Service, а datapath направляет соединение к одному из реальных backend pod.
В зависимости от реализации это может делать kube-proxy или другой механизм сетевого плагина.
Для расследования ИБ это создаёт нюанс: на разных уровнях логирования один и тот же поток может выглядеть по-разному. Где-то будет виден Service IP, где-то — реальный IP backend pod.
Поэтому желательно хранить Kubernetes metadata вместе с сетевыми событиями.
Почему внешний firewall видит не всё
Пакет между двумя pod на одной node может вообще не попасть во внешнюю физическую сеть.
Между nodes путь зависит от CNI.
От выбранной реализации зависят место применения NetworkPolicy, видимость east-west, возможность зеркалирования, видимость исходного pod IP, журналирование flow и способы контроля egress.
Минимальный паспорт сети кластера
Для первичной схемы полезно зафиксировать:
Cluster:
nodes:
pod CIDR:
service CIDR:
CNI:
overlay/route mode:
ingress:
egress:
NetworkPolicy support:
flow logging:
Даже такой простой паспорт резко упрощает дальнейший анализ.
Главное
Kubernetes-сеть не является «чёрным ящиком». Она построена на обычных сетевых принципах, но добавляет динамическую идентичность workload и программно управляемый datapath.
Пока специалист не понимает, как пакет проходит от pod A к pod B, говорить о защите преждевременно.
В следующей статье разберём north-south и east-west и покажем, где именно появляется слепая зона периметрового firewall.