DevSecOps для самых маленьких: 5\n. Микросегментация: как построить стены внутри базы

В прошлый раз мы разобрались с харденингом — сделали контейнеры крепкими, убрали root, добавили лимиты. Но есть проблема. Если один под всё-таки взломали, он может спокойно пойти гулять по всему кластеру. Никто его не остановит, потому что внутри сети все друг друга видят.

В Minecraft это как база без внутренних стен: пока крипер снаружи — забор спасает, а если он уже внутри — одна большая комната, и ничто его не остановит. Микросегментация — это про стены между комнатами.

Что такое микросегментация — это разделение сети на мелкие зоны, чтобы один скомпрометированный сервис не мог свободно общаться со всеми остальными.

В обычной сети есть фаервол на входе. Он защищает периметр. Но внутри сети всё открыто: база данных, кэш, очереди, админка — всё видно и доступно. Если атакующий попал внутрь, он ходит по сети как по своему дому.

В Kubernetes это особенно опасно, потому что поды переезжают, IP меняются, и традиционные IP-фаерволы просто не работают. Нужна identity-based сегментация: не «этому IP можно туда», а «этому сервису можно только к этому сервису».

Почему дефолт — это дыра

В Kubernetes по умолчанию весь трафик между подами разрешён. Все видят всех. Никаких ограничений.

Это называется flat network. И это удобно, когда ты только начинаешь. Но с точки зрения безопасности — катастрофа.

Представь: у тебя есть фронтенд, бэкенд и база данных. Если фронтенд взломали, он может напрямую подключиться к базе данных. Не должен, но может — потому что никто не запрещает.

Или хуже: у тебя есть под, который вообще не должен ни с кем общаться, кроме одного сервиса. Но он видит весь кластер. Если в нём дыра — атакующий получит доступ ко всему.

Что такое NetworkPolicy

NetworkPolicy — это встроенный механизм Kubernetes для микросегментации. Он позволяет описать правила: кто, куда и на какой порт может ходить.

По умолчанию, если NetworkPolicy не настроена, весь трафик разрешён. Но как только ты создаёшь первую политику — она начинает работать.

Главное правило: default deny. Сначала запретить всё, потом разрешить нужное. Не наоборот.

Пример: ты создаёшь политику, которая говорит «весь входящий трафик запрещён для всех подов в namespace». После этого никто никуда не может ходить. Потом ты добавляешь правила: «фронтенду можно к бэкенду», «бэкенду можно к базе». И всё — сеть сегментирована.

Что конкретно сегментировать

Первое — база данных. К ней должны ходить только те сервисы, которым это действительно нужно. Не весь кластер, а конкретные поды.

Второе — админка. Если у тебя есть внутренняя панель управления, к ней не должен ходить никто, кроме тех, кому положено.

Третье — мониторинг. Prometheus и Grafana должны видеть метрики, но не должны иметь доступ к базам данных.

Четвёртое — очереди и кэши. Redis, RabbitMQ, Kafka — к ним ходят только те, кому нужно.

Пятое — внешние интеграции. Если под ходит в интернет, он должен ходить только туда, куда разрешено. Egress-политики не менее важны, чем ingress.

Инструменты

Open source: Kubernetes NetworkPolicy — база, с неё начинают все. Cilium — eBPF-based, L7-политики, Hubble для наблюдаемости. Calico — зрелый CNI с tiered policies. Istio — service mesh с mTLS и RBAC-based сегментацией. KubeArmor — микросегментация и runtime-политики, в том числе для VM.

Российские решения: Deckhouse Kubernetes Platform — микросегментация сети с автогенерацией политик на базе Cilium, VLAN-изоляция рабочих сред. Luntry — контроль сетевых событий и предотвращение сетевых угроз в контейнерах.

С чего начать

Первое — включить NetworkPolicy в кластере. Не во всех CNI она работает из коробки, проверь.

Второе — создать default deny для одного namespace. Например, для тестового. Посмотреть, что сломалось. Обычно ломается всё, потому что никто не ожидал, что трафик вдруг перестанет ходить.

Третье — добавить правила для одного сервиса. Самого простого. Фронтенд к бэкенду. Убедиться, что работает.

Четвёртое — постепенно расширять. По одному сервису за раз. Не пытайся сегментировать весь кластер за ночь.

Пятое — настроить мониторинг. Cilium Hubble или просто логи. Смотреть, какие соединения блокируются. Иногда блокируется что-то важное, и это надо вовремя заметить.

Главное

Микросегментация — это не про то, чтобы всё запретить. Это про то, чтобы разрешить только нужное. Стены в базе не мешают тебе ходить по комнатам, но останавливают того, кто пришёл без приглашения.

Без микросегментации остальные практики DevSecOps работают вполсилы. Можно спрятать секреты в Vault, но если под взломали, он может пойти к базе данных напрямую. Можно харденить контейнеры, но если сеть открыта, атакующий всё равно найдёт путь.

Начни с default deny. Потом добавь одно правило. Потом второе. Через месяц твой кластер будет сегментирован, и ты будешь спать спокойнее.