Раздел

Kubernetes

Блог

Как устроена сеть Kubernetes: pod, Service, CNI, underlay и overlay простыми словами

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

13.09.2026 4 минуты Открыть →

Блог

Почему привычная сетевая безопасность не работает в Kubernetes так же, как в обычной сети

<p>Если специалист по информационной безопасности привык работать с физическими серверами, виртуальными машинами, VLAN и межсетевыми экранами, Kubernetes сначала выглядит непривычно. Причина не в том, что в нём «другая сеть». IP-адреса, TCP, UDP, DNS и маршрутизация никуда не исчезают. Меняется сам объект, вокруг которого строится политика безопасности.</p> <p>В обычной инфраструктуре сервер или виртуальная машина могут годами сохранять один и тот же адрес и выполнять одну и ту же функцию. Поэтому правило вида «сервер приложений 10.10.20.15 может обращаться к БД 10.10.30.10 по TCP/5432» выглядит естественно.</p> <p>В Kubernetes конкретный экземпляр приложения — pod — может быть уничтожен и создан заново автоматически. Новый pod может получить другой IP-адрес и запуститься уже на другой worker node. Для приложения это штатное поведение, а не авария.</p> <p>Отсюда следует главный вывод: <strong>в Kubernetes нельзя строить долговременную модель безопасности только вокруг текущих IP-адресов pod</strong>.</p> <h2>Что такое pod и почему он важен для сети</h2> <p>Pod — минимальная единица размещения workload в Kubernetes. Проще говоря, это оболочка, внутри которой запускается один или несколько тесно связанных контейнеров.</p> <p>Контейнеры внутри одного pod используют общий сетевой namespace. Это означает, что у них общий IP-адрес и общий набор сетевых интерфейсов. Между собой они могут обращаться через <code>localhost</code>.</p> <p>С точки зрения сетевой безопасности pod обычно рассматривается как единый сетевой endpoint.</p> <p>Важно не путать pod и container:</p> <ul> <li>container — запущенный экземпляр контейнерного образа;</li> <li>pod — объект Kubernetes, в котором выполняются один или несколько контейнеров;</li> <li>NetworkPolicy выбирает pod, а не отдельный контейнер внутри него.</li> </ul> <h2>Почему IP pod нельзя считать постоянным</h2> <p>Представим обычный web-сервис. В Kubernetes он может быть описан как Deployment с тремя репликами:</p> <pre><code class="language-text">frontend-1 10.244.1.12 frontend-2 10.244.2.7 frontend-3 10.244.3.18 </code></pre> <p>Один из pod завершился. Kubernetes создаёт новый:</p> <pre><code class="language-text">frontend-4 10.244.4.9 </code></pre> <p>Сервис продолжает работать. Но набор конкретных IP изменился.</p> <p>Если политика безопасности была жёстко привязана к <code>10.244.1.12</code>, она больше не описывает логическую роль приложения.</p> <p>Поэтому в Kubernetes используются более устойчивые признаки: namespace, labels, service account, принадлежность к workload, логическое имя Service и назначение приложения.</p> <h2>Для чего нужен Service</h2> <p>Другим приложениям неудобно постоянно отслеживать адреса отдельных pod. Kubernetes решает эту проблему с помощью объекта Service.</p> <p>Service предоставляет стабильную логическую точку доступа к группе pod:</p> <pre><code class="language-text">frontend Service | +-- frontend pod A +-- frontend pod B +-- frontend pod C </code></pre> <p>Pod могут меняться, а Service остаётся.</p> <p>Это важное изменение мышления: в контейнерной среде нужно всё чаще оперировать <strong>ролью и идентичностью workload</strong>, а не конкретным сервером.</p> <h2>Почему firewall перед кластером недостаточен</h2> <p>Допустим, схема выглядит так:</p> <pre><code class="language-text">Internet | [WAF] | [NGFW] | Kubernetes </code></pre> <p>На первый взгляд кажется, что кластер защищён.</p> <p>Но внутри Kubernetes frontend может обращаться к backend, backend — к другим микросервисам, а часть workload — к внешней БД. Эти соединения могут не проходить через периметровый firewall.</p> <p>То есть внешний NGFW хорошо видит трафик, входящий в кластер и выходящий из него, но не обязательно видит все внутренние связи.</p> <p>Это называют различием:</p> <ul> <li><strong>north-south</strong> — трафик между кластером и внешними системами;</li> <li><strong>east-west</strong> — внутренние взаимодействия workload.</li> </ul> <p>Периметровая защита нужна, но для east-west необходимо отдельное управление.</p> <h2>Namespace не является сетевым экраном</h2> <p>Ещё одна типичная ошибка: считать, что два приложения в разных namespace автоматически изолированы друг от друга.</p> <p>Это не так.</p> <p>Namespace — логическая область Kubernetes API. Он помогает разделять объекты, права, имена и квоты. Но сам по себе он не запрещает сетевое взаимодействие.</p> <p>Сетевую границу создаёт NetworkPolicy или другой механизм фильтрации.</p> <h2>Как меняется базовая модель защиты</h2> <p>В обычной инфраструктуре специалист может думать так:</p> <pre><code class="language-text">IP → VLAN → ACL → firewall </code></pre> <p>В Kubernetes появляется дополнительный уровень:</p> <pre><code class="language-text">workload identity | namespace / labels / service account | NetworkPolicy / CNI | IP-сеть и маршрутизация </code></pre> <p>То есть IP остаётся важным, но перестаёт быть единственным идентификатором.</p> <h2>Что должен проверить ИБ-специалист в первую очередь</h2> <p>Если в организации уже появился Kubernetes, не стоит начинать с покупки дополнительного средства защиты.</p> <p>Сначала необходимо получить ответы на простые вопросы:</p> <ol> <li>Сколько Kubernetes-кластеров существует?</li> <li>Где они размещены?</li> <li>Какие приложения в них работают?</li> <li>Какой сетевой плагин используется?</li> <li>Есть ли NetworkPolicy?</li> <li>Реально ли они применяются?</li> <li>Какие сервисы опубликованы наружу?</li> <li>Куда workload могут ходить из кластера?</li> <li>Собирается ли информация о внутренних сетевых потоках?</li> <li>Кто имеет право менять сетевые политики?</li> </ol> <p>Эти вопросы дают гораздо больше информации о реальном состоянии защиты, чем сам факт наличия NGFW перед кластером.</p> <h2>Главное</h2> <p>Kubernetes не отменяет привычную сеть. Он делает инфраструктуру динамической.</p> <p>Поэтому вместо подхода «защитим конкретный сервер с конкретным IP» появляется подход: «защитим workload с определённой ролью независимо от того, где именно он сейчас запущен и какой IP получил».</p> <p>В следующей статье разберём, как именно устроена сеть Kubernetes: что такое node, pod network, Service, CNI, underlay и overlay и по какому пути реально идёт сетевой пакет.</p>

12.09.2026 5 минут Открыть →