7 ошибок в Kubernetes NetworkPolicies: от намерения к реальности

Сетевые политики Kubernetes не гарантируют безопасность без проверки

Сетевые политики Kubernetes (NetworkPolicies) являются мощным инструментом для обеспечения безопасности, но их неправильное применение создает иллюзию защищенности. Инструмент декларирует намерение, например, "этот под должен принимать соединения только на порт 8443 из пространства имен ingress". Однако декларация намерения не означает его фактическое выполнение. В серии статей рассматривается применение сетевых политик в Red Hat OpenShift в рамках паттерна Layered Zero Trust Validated Pattern (ZTVP). В предыдущих материалах обсуждались политики как последний рубеж обороны при невозможности быстрого исправления уязвимостей и роль Red Hat Advanced Cluster Security for Kubernetes в качестве центрального механизма для обеспечения соблюдения границ безопасности в реальном времени. Данная статья фокусируется на распространенных ошибках при реализации сетевых политик и методах их проверки.

"У меня есть политики, значит, я в безопасности" — распространенное заблуждение

Многие команды полагаются на политики для отдельных подов, не устанавливая базовую политику "запретить всё по умолчанию" (default-deny). Без такой политики любой под, не соответствующий существующим правилам, получает неограниченный сетевой доступ. Это позволяет злонамеренному поду с общим идентификатором (label) получать доступ к любым сервисам через DNS, подключаться к Vault в других пространствах имен и эксфильтровать данные в интернет. Примером может служить ситуация, когда под в пространстве имен qtodo смог обнаружить и подключиться к Vault, центральному узлу Red Hat Advanced Cluster Security и интернету, в то время как был защищен только под базы данных.

Игнорирование исходящего трафика (egress) создает уязвимости

Команды часто концентрируются только на входящем трафике (ingress), забывая о контроле исходящего трафика (egress). Отсутствие строгих ограничений на исходящие соединения позволяет скомпрометированному поду выполнять разведку через DNS, подключаться к серверу API Kubernetes для перечисления ресурсов кластера, связываться с внешними командно-контрольными серверами (C2) и эксфильтровать данные. В ZTVP для каждого пода определены явные правила исходящего трафика. DNS-запросы ограничиваются сервисом CoreDNS кластера, доступ к API Kubernetes предоставляется только необходимым подам, а исходящий трафик в интернет запрещен, если это не обосновано бизнес-логикой.

Специфические особенности платформы влияют на работу политик

Сетевые политики Kubernetes являются стандартным API, но их поведение зависит от используемого сетевого плагина Container Network Interface (CNI). Например, в OpenShift с OVN-Kubernetes DNS использует порт 5353, а не 53. Политика, разрешающая исходящий трафик на порт 53, не позволит подам разрешать имена хостов. Конечные точки сервера API Kubernetes после DNAT являются IP-адресами узлов, поэтому для их сопоставления требуется правило только по порту 6443, а не селектор пространства имен. Поды с hostNetwork: true полностью освобождаются от действия сетевых политик. Это требует документирования таких исключений, а не предположения, что стандартные политики их покрывают.

Тестирование на реальном кластере необходимо для подтверждения работоспособности

Корректно сгенерированная сетевая политика не всегда обеспечивает безопасность во время выполнения. Проверка на работающем кластере необходима для подтверждения работоспособности всех подов, доступности сервисов и корректной работы зависимостей в других пространствах имен. В ZTVP перед внесением изменений в сетевые политики выполняется "сухой прогон" (dry run) на живом кластере. Политики применяются, проверяются все сетевые потоки, перезапускаются критические поды, анализируются журналы на предмет ошибок подключения. Только после успешного завершения "сухого прогона" изменения фиксируются в системе контроля версий.

Ловушки булевых значений в шаблонах Argo CD приводят к незаметным сбоям

При использовании шаблонов NetworkPolicy, управляемых значениями (например, enabled: true), распространенная ошибка заключается в передаче булевых значений как строк ("true" вместо true) через Helm. Условие шаблона {{- if .Values.networkPolicy.enabled }} в таком случае не срабатывает, политика не генерируется, и пользователь остается в заблуждении относительно сетевой изоляции. Для предотвращения таких ошибок рекомендуется использовать {{- if eq (.Values.networkPolicy.enabled | toString) "true" }}. Инструменты вроде Chart Testing помогают проверять конфигурации Helm-чартов перед их развертыванием в кластере.

Аддитивная семантика политик усложняет устранение неполадок

Когда несколько сетевых политик применяются к одному поду, их правила суммируются (аддитивно), а не переопределяют друг друга. Эффективная политика представляет собой объединение всех соответствующих правил. Невозможно создать ограничивающую политику, которая сузит действие более широкой. Если Политика A разрешает порт 8080 из любого источника, а Политика B разрешает его только из пространства имен X, то под будет принимать трафик на порт 8080 из любого источника. Это усложняет поиск причин непреднамеренно разрешенных соединений, так как необходимо анализировать каждую политику, применяемую к поду.

Ограничения сетевых политик и дилемма AdminNetworkPolicy

Стандартные сетевые политики Kubernetes имеют область действия в пределах пространства имен. Администратор кластера не может определить политику "запретить всё по умолчанию" для всего кластера с помощью стандартного API. Для этого в Kubernetes введена политика AdminNetworkPolicy (ANP), которая имеет область действия в пределах кластера. ANP предназначены для установки общих правил инфраструктуры, например, "пространства имен арендаторов не должны взаимодействовать друг с другом". Однако ANP не покрывают микросегментацию на уровне пространства имен. Если администратор применяет глобальное правило "запретить всё" через ANP, оно имеет высокий приоритет и переопределяет политики разработчиков. Это может помешать работе приложений, требующих определенных сетевых подключений. Хотя BaselineAdminNetworkPolicy (BANP) позволяет установить базовый запрет, который разработчики могут переопределить, полагаться исключительно на глобальные политики для управления микросегментацией приложений является антипаттерном. В ZTVP используется многоуровневый подход с микросегментацией на уровне приложений, применяя политики с учетом значений через шаблоны Helm для обеспечения базового запрета в пределах пространства имен.

Инструменты для анализа и проверки сетевых политик

Существуют инструменты для генерации сетевых политик из манифестов Kubernetes, которые анализируют YAML-файлы и предлагают политики на основе предполагаемой связности. Однако статический анализ имеет ограничения: он не учитывает реальные сетевые потоки во время выполнения, специфику платформы (например, порт DNS в OpenShift) и динамические изменения, вносимые операторами. Сгенерированные политики являются лишь предложениями и требуют проверки на реальном кластере. Инструменты наблюдения за сетевыми потоками в реальном времени, такие как Red Hat Advanced Cluster Security, предоставляют карту сетевой топологии, выявляют неожиданные соединения и помогают определить базовые потоки для создания правил. Это позволяет замкнуть цикл: разработка политик на основе анализа архитектуры, их применение и последующая проверка с помощью наблюдения за реальным трафиком. AI-агент Network Policy Architect анализирует исходный код, Helm-чарты и документацию для определения потоков связи, выявляет особые случаи и составляет первоначальные правила. Затем он подключается к работающему кластеру, применяет предложенные политики в режиме "сухого прогона" и записывает результаты проверки.

Источник: Red Hat Security