Настройка Docker Networks: изоляция и сегментация контейнеров

Контейнеры видят друг друга: где ломается Docker networks изоляция

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

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

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

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

Что даёт сегментация: меньше точек входа и предсказуемый трафик

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

В Docker сеть по умолчанию объединяет весь стек, поэтому первый шаг — развести роли по назначению. Что проверяем после разделения:

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

Правила проверяем тестами связности: разрешённые пары отвечают, запрещённые молчат. Иначе сегментация остаётся в схеме, но не в работающей системе.

Сравнение режимов: стандартная, пользовательская, host и overlay сеть

Режим сети выбирают по задаче, а не по привычке: одна и та же конфигурация на стенде разработчика и в кластере ведёт себя по-разному. Ниже — сопоставление четырёх вариантов, которые даёт Docker, по условиям применимости и ограничениям.

Когда режим вредит

host на узле с несколькими приложениями приводит к конфликту портов и снимает сегментацию. overlay для одного узла даёт только накладные расходы на инкапсуляцию без выигрыша в изоляции.

Несколько сетей у сервиса

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

Порядок работ: от инвентаризации сервисов до передачи схем

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

1. Инвентаризация сервисов и связей. Собираем перечень контейнеров, опубликованных наружу портов и обращений «кто к кому ходит». Источники — файлы запуска, журналы, карта зависимостей от разработчиков. На выходе — таблица связей с указанием порта и направления.

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

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

4. Правила доступа между сегментами. Межсетевые связи открываем поимённо и там, где они обоснованы задачей. Всё остальное закрыто — так новая уязвимость в одном сервисе не даёт доступа к соседям.

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

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

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

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

Что остаётся у команды: схемы сетей, политики, регламенты

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

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

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

Изоляция сервисов в проде: кейс с метриками до и после

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

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

Что показали замеры до и после

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

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

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

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

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

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

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

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

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

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

Что публиковать наружу, а что оставлять внутри?

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

Изоляция замедлит обмен между сервисами?

Нет. Изоляция — это правила маршрутизации на хосте, а не лишний сетевой участок. Задержка растёт на доли миллисекунды и теряется на фоне запроса к базе; разница видна только в синтетических замерах.

Как проверить, что изоляция действительно действует?

Обратным тестом: поднимаем временный контейнер в одной сети и пробуем достучаться до сервиса из другой — соединение устанавливаться не должно. Сверяем docker network inspect и список сетей у контейнера с проектной схемой.

Обсудим вашу схему сети: что прислать для оценки и плана

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

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

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