Вы запускаете несколько сервисов в Docker. База данных, бэкенд, фронтенд. По умолчанию они часто видят друг друга. Это удобно для разработки, но в продакшене похоже на дом, где все внутренние двери распахнуты настежь. Что, если в одном сервисе обнаружится уязвимость? Злоумышленник или сбойный код сможет «прогуляться» по всей вашей системе.
Задача – не просто изолировать контейнеры от внешнего мира, но и управлять тем, как они общаются между собой. Это называется сегментацией сети, и это основа безопасности микросервисной архитектуры.
Базовый принцип: от общей гостиной к отдельным комнатам
По умолчанию контейнеры в одной пользовательской bridge network в Docker могут свободно связываться по любым портам. Первый шаг к порядку – разделить их логически.
Создавайте отдельные сети для разных групп сервисов. Например, сеть `internal` для бэкенда и базы данных и сеть `public` для фронтенда и балансировщика. В Docker Compose это делается в несколько строк. Контейнеры из разных сетей по умолчанию не увидят друг друга. Это как поселить семьи в разные подъезды.
Сетевые политики в Kubernetes: настоящий КПП
В Kubernetes логическое разделение через namespace – только начало. Настоящую мощь дают сетевые политики (Network Policies). Они работают как детализированные правила фильтрации на уровне всего кластера.
Представьте, что каждый под – это отдельное здание. Сетевая политика – это охранник на въезде, который сверяется со списком. «Ты – сервис корзины покупок? Тебе разрешено говорить только с сервисом базы данных заказов на порт 5432. Всё остальное – запрещено». Так вы ограничиваете ингрес (входящий трафик) и эгресс (исходящий трафик) для каждого приложения.
Как это выглядит на практике
Вы пишете манифест, где указываете:
- podSelector: К каким подам применить правило (например, все с меткой `app=payment`).
- policyTypes: `Ingress`, `Egress` или оба.
- ingress/egress: Конкретные разрешения – откуда (`from`) и куда (`to`) можно обращаться, и на какие порты.
Если политика запрещает все, а вы явно не разрешили связь – её не будет. Это принцип «запрещено по умолчанию».
Инструменты реализации: Calico, Cilium и другие
Сами по себе политики в Kubernetes – это только декларация. Их реализуют сетевые драйверы или плагины, такие как Calico или Cilium. Они преобразуют ваши правила в низкоуровневые команды для iptables или firewall на узлах кластера, либо работают через свои механизмы фильтрации в overlay network.
Cilium, например, оперирует понятиями на уровне приложений (HTTP, gRPC), что делает правила более осмысленными. Calico часто ассоциируется с гибкостью и производительностью. Выбор зависит от потребностей в мониторинге, сложности правил и среды.
Антипример: что бывает без контроля
Допустим, у вас есть сервис генерации PDF, который по ошибке или из-за уязвимости начинает сканировать порты других контейнеров. Без правил фильтрации он может найти открытый порт менеджера баз данных или даже попасть в служебный поды системы мониторинга. С политиками его исходящий трафик будет ограничен только необходимым хостом API, и атака будет локализована.
С чего начать: практические шаги
- Картографируйте зависимости. Запишите, какой сервис с каким и на каком порту должен общаться. Это основа для правил.
- Внедряйте постепенно. Начните с неймспейсов и логических сетей в Docker или Docker Compose. Затем, в Kubernetes, создайте политику, которая сначала только логирует трафик (в режиме аудита, если плагин поддерживает), а потом переводите в режим жесткого запрета.
- Тестируйте. После применения политик убедитесь, что легитимные связи работают, а запрещённые – блокируются. Попробуйте запустить `curl` или `telnet` из одного пода к другому.
Ограничение межконтейнерного взаимодействия – это не паранойя. Это зрелый подход к безопасности и стабильности. Вы не просто защищаетесь от внешних угроз, но и создаёте «пожарные отсеки» внутри системы. Ошибка в одном модуле не приведёт к коллапсу всего приложения. Ваш трафик становится предсказуемым, а архитектура – надёжной и понятной.
В конечном счёте, грамотное управление доступом экономит нервы и время. Вы тратите часы на настройку, но спасаете дни на расследовании инцидентов. Это разумный компромисс, который оценят все, кто отвечает за работу ваших сервисов.