Настройка Network Security Policies для Kubernetes (Calico/Cilium)

Network Security Policies: почему трафик между сервисами открыт

По умолчанию сеть внутри кластера плоская: поды видят друг друга напрямую, а маршрут между узлами не требует подтверждения. Пока Network Security Policies не заданы, любой сервис может обратиться к базе, брокеру очередей или внутреннему API — не потому что так задумано, а потому что ничто этого не запрещает.

Цена такой картины видна при первом же сбое: ошибка конфигурации или компромисс в одном сервисе открывает доступ к соседним, а через тот же открытый трафик между сервисами — к внешним системам и хранилищам. Разбираем, как это закрывается.

Сегментация нагрузки строится на трёх вопросах: кто инициирует соединение, куда и на каком порту. Правило описывают селекторами меток подов и пространств имён, поэтому изоляция трафика в кластере не привязана к адресам и не ломается при пересоздании подов. Режим «запрещено всё, кроме разрешённого» включают первым, а исключения добавляют точечно — по фактическим связям, а не по предположениям.

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

Изоляция трафика между средами: классы отказов и время реакции

Сегментация начинается с режима запрета по умолчанию (default-deny): в каждом пространстве имён входящий и исходящий трафик закрыт, дальше открываются только нужные пары «сервис — сервис» и порты. Правила описывают не «кому можно», а «кому нельзя иначе» — связи видны из манифестов, а не реконструируются по журналам. Подход поддерживают распространённые сетевые дополнения, включая Calico, и переносится между ними почти без переписывания правил.

Какие классы отказов перестают распространяться: утечка учётных данных в тестовом пространстве имён больше не даёт доступа к боевой базе, а заражённый под не сканирует соседей — боковое перемещение обрывается на первом запрете. Ошибка конфигурации, из-за которой сервис лезет в чужое хранилище, перехватывается сетью, а не выясняется по испорченным данным.

Время разбора инцидента падает, потому что политика — это исполняемая схема связей. Дежурный видит разрешённые потоки и отсекает половину гипотез сразу, а сработавший запрет пишется отдельным событием — цепочку «кто к кому ходил» не нужно собирать по крупицам.

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

Network Security Policies: режимы контроля и ограничения

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

Четыре уровня изоляции

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

Порядок внедрения обычно такой: включаем штатные политики в режиме наблюдения, собираем по журналам реальные связи, переводим наблюдение в блокировку и только затем добавляем узловые правила и взаимную проверку там, где нужна защита от перемещения по сети.

Порядок внедрения: от инвентаризации трафика до передачи

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

1. Инвентаризация трафика. Собираем журналы сетевых потоков, запросы DNS и метрики сервисной сетки за период, который покрывает и регулярные задачи, и ночные регламенты. На выходе — матрица «сервис → сервис → порт».
2. Схема разрешённых связей. Оставляем подтверждённые связи, спорные согласуем с владельцами сервисов. Базовая линия — запрет всего, что не описано явно.
3. Настройка в тестовом контуре. Переносим политики на копию кластера и включаем в режиме логирования: правила считаются, трафик не режется. Так набираем срабатывания на реальном профиле нагрузки без риска.
4. Проверка политик. Прогоняем легитимные цепочки и сквозные пути мониторинга, сборщиков журналов и реестра образов: разрешённое проходит, лишнее фиксируется в отчёте.
5. Поэтапное включение правил. Переводим пространства имён в блокирующий режим по одному, начиная с некритичных контуров. Перед каждым шагом — контроль метрик доступности.
6. Разбор блокировок. По журналам отделяем вредный трафик от незадокументированной, но нужной связи: либо точное исключение, либо исправление самого сервиса.
7. Передача команде. Отдаём политики в системе контроля версий, регламент изменений, схему связей и инструкцию дежурному. Откат — переключение на предыдущий набор правил.

Манифесты, схемы потоков и регламент изменений

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

• Реестр разрешённых потоков — кто с кем общается, по какому порту и какой сервис отвечает за связь. На него ссылаются при разборе сбоя и при выводе сервиса из эксплуатации.
• Готовые конфигурации политик — манифесты с понятными именами, разбитые по пространствам имён, с пометками, какие правила обязательные, а какие временные. Выкатываются как есть.
• Схема доверия — карта сегментов и направлений трафика: что считаем внешним периметром, что внутренней зоной, где допускается обращение между средами и средами разработки.
• Регламент изменений — порядок правки: заявка с обоснованием, проверка в тестовом контуре, окно выката, ответственный за согласование. Без него правила быстро превращаются в свалку исключений.
• Журнал блокировок и порядок разбора — куда смотреть при отказе сервиса, как отличить ложное срабатывание от реальной попытки связи и за какое время правило снимается.
• Инструкция по откату — как вернуть предыдущий набор правил одной операцией, если после изменения посыпались зависимости.
• Приёмочные сценарии — перечень связей, которые проверяются после каждой правки, чтобы регресс ловился до рабочего контура.

Комплект ведётся в репозитории вместе с манифестами, поэтому документация не расходится с фактическим состоянием кластера: изменение политики и изменение её описания идут одним согласованным действием.

Кейс: сегментация кластера без простоя сервисов

До: плоская сеть

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

Что изменили

Сначала сняли трафик за несколько циклов релизов и построили граф зависимостей «сервис → сервис → порт» — он и стал источником правил. Политики описывали в Calico: сперва в режиме логирования, когда связи только фиксируются, но не блокируются, затем включили запрет по умолчанию и точечные разрешения. Каждой среде дали собственный набор правил, поэтому предпродукт и тестовый контур перестали маршрутизироваться в продуктив.

Результат

Доля разрешённых связей сократилась со 100% до 11% — остальное закрыто явными запретами. Разбор инцидента ускорился в разы: вместо обхода узлов достаточно посмотреть журнал отклонённых соединений, 30–40 минут вместо половины рабочего дня. Правила включали без остановки нагрузки: дежурный контролировал поток отказов, откат к предыдущему профилю занимал минуты, окна простоя не потребовалось.

Чем сетевые политики отличаются от ролей доступа?

Роли доступа и сетевые политики закрывают разные вопросы, и путаница между ними оставляет дыры в защите. Роли разграничивают права: какая учётная запись может читать, создавать и менять объекты в системе управления. Политики на уровне сети отвечают на другой вопрос — какие соединения между нагрузками вообще возможны.

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

Разница видна на примере. Учётной записи сервиса разрешено читать секреты в своём пространстве имён — роль это позволяет, и это нормально. Но это не значит, что тот же сервис должен ходить в базу биллинга: политика запрещает соединение, и при компрометации пода злоумышленник не попадёт в чужой контур.

По умолчанию в кластере без политик трафик между пространствами имён открыт. Поэтому внедрение начинают с запрета по умолчанию и явных разрешений по селекторам подов: только нужные пары «сервис → сервис» и исходящий доступ к DNS. Calico и Cilium применяют такие правила на сетевом уровне и отбрасывают соединение до того, как оно дойдёт до приложения.

Сравнение механизмов сводится к зоне ответственности: роли отвечают за управление кластером и его объектами, политики — за связи между нагрузками. Аудит тоже разный: изменения прав видны в журнале системы управления, отклонённые соединения — в счётчиках узла. Модель доступа работает, только когда настроены оба слоя.

Технические сомнения: совместимость, откаты, поддержка

Политики сетевой безопасности меняют то, как ходит трафик внутри кластера, поэтому сомнения у команд почти всегда одинаковые. Отвечаем на те, что задают чаще всего до старта.

Что будет с правилами, которые уже есть в кластере?

Инвентаризируем всё, что описано манифестами, и сводим в единый набор с проверкой приоритетов: при пересечении результат решает порядок применения. Контроллеры считают этот порядок по-разному, поэтому два в одном кластере не смешиваем — остаётся один.

Как откатить изменения, если доступ пропал?

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

Кто сопровождает политики после передачи?

Отдаём репозиторий с правилами, схему потоков между сервисами и инструкцию по диагностике: по каким журналам видно, что именно отброшено. Первое время остаёмся на связи и правим правила вместе с вашей командой, пока она не выйдет на самостоятельный режим.

Старт работ: что нужно с вашей стороны и сроки

Порядок старта одинаков и для одного кластера, и для парка из десятков: сначала входные данные, затем оценка работ, потом согласованный план внедрения со сроками. Без схемы сред и перечня сервисов оценка превращается в вилку, а Network Security Policies приходится перепроектировать по ходу — поэтому сбор данных выносим в первый шаг и фиксируем результат письменно.

• Схема сред: кластеры прода, предпродуктивного контура и разработки, их связи между собой и с внешними сетями.
• Перечень сервисов: кто с кем общается, какие внешние адреса и порты нужны, где трафик идёт в обе стороны.
• Точки входа: балансировщики, шлюзы, публикация сервисов, доступы к DNS и реестру образов.
• Учётные данные: отдельная роль с правом читать политики и включённый режим аудита в тестовом контуре.
• Целевые требования: что именно ограничиваем — связи между пространствами имён, выход в интернет, доступ к базам данных.
• Ограничения: окна, в которые допустимы изменения в проде, и сервисы, которые нельзя останавливать.
• Ответственный с вашей стороны: инженер, который подтверждает связи и принимает результат.

Дальше возвращаемся с оценкой по этапам и планом: пилот в тестовом контуре в режиме аудита, когда политики только логируют трафик и ничего не блокируют, сверка журнала с реальными связями, перевод в режим блокировки по одному пространству имён, затем прод. От обсуждения задачи до пилота проходят дни, до полного перевода — недели; точный срок зависит от числа сервисов и связей между ними.