Kubernetes. Как защитить трафик кластера с помощью сетевых политик Pod.

Модули Kubernetes по умолчанию могут свободно взаимодействовать друг с другом. Это создает угрозу безопасности, когда ваш кластер используется для нескольких приложений или групп. Ошибочное поведение или вредоносный доступ в одном модуле могут перенаправить трафик на другие модули в вашем кластере.

В этой статье вы узнаете, как избежать этого сценария, настроив сетевые политики. Эти правила позволяют управлять потоками трафика Pod-Pod на уровне IP-адресов (уровень OSI 3 или 4). Вы можете точно определить источники входа и выхода, разрешенные для каждого Pod

Создание сетевой политики

Сетевые политики создаются путем добавления NetworkPolicy объектов в ваш кластер. Каждая политика определяет модули, к которым она применяется, и одно или несколько правил входа и выхода. Вот основной политический манифест:

: Апиверсия networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация приложения: подСелектор: Метки соответствия: компонент: типы политик базы данных: - Вход
 - Вход выхода: - из: - подселектора: соответствующие метки: компонент: api выход: - в: - Подселектора: соответствующие метки: компонент: api

Эта сетевая политика применяется к любому модулю с component: databaseметкой в appпространстве имен. В нем указано, что входящий (входящий) и исходящий (исходящий) трафик разрешен только из и в модули с component: apiметкой. Любые запросы, исходящие от других модулей, таких как component: web-frontend, будут заблокированы.

Сетевые политики могут быть применены, как и любой другой объект, с помощью Kubectl. Они вступят в силу сразу же после их создания. Вы можете добавить сетевую политику перед запуском выбранных ею модулей.

$ kubectl применить -f policy.yaml
networkingpolicy.networking.k8s.io/network-policy созданный

Как работают сетевые политики

Сетевые политики реализуются подключаемым модулем active networking вашего кластера. Ваши политики не будут иметь никакого эффекта, если ваш плагин не поддерживает эту функцию. Самые популярные опции, такие как Calico и Cilium, поставляются с включенной поддержкой сетевых политик.

Когда сетевая политика применяется к Pod, плагин проверяет его трафик на соответствие требованиям политики. Любые подключения, которые не соответствуют критериям, будут запрещены. Модуль, который пытался инициировать соединение, обнаружит, что удаленный хост недоступен, либо потому, что он пытался получить доступ к ресурсу, заблокированному правилом выхода, либо потому, что удаленный модуль отклонил входящее соединение, используя правило входа.

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

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

Пример сетевых политик

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

Примените политику к каждому Pod в пространстве имен, разрешающую входящий трафик только с определенного блока IP-адресов

: apiVersion networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация приложения: подСелектор: {} Типы политик: - Вход входящий: - от: - IP-блок: cidr: 172.17.0.0/16

Пустой podSelectorблок означает, что политика нацелена на все модули пространства имен. ipBlockПравило ограничивает входящий трафик для модулей с IP-адресом в указанном диапазоне. Исходящий трафик не блокируется.

Разрешить входящий трафик с блока IP-адресов, но исключить некоторые конкретные IP-адреса

: Апиверсия networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация приложения: подСелектор: {} Типы политик: - Вход входящий: - от: - IP-блок: cidr: 172.17.0.0/16 кроме: - 172.17.0.1/24
 - 172.17.0.2/24
 - 172.17.0.3/24

ipBlock правила поддерживают exceptполе для исключения трафика, исходящего от определенных IP-адресов или направляемого на них.

Разрешить входящий трафик из всех модулей в пространстве имен, но только с определенного порта

: Апиверсия networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация приложения: подСелектор: {} Типы политик: - Вход входящий: - от: - подСелектор: {} порты: - протокол: TCP порт: 443

Это portsполе доступно в правилах входа и выхода. Он определяет порты, с которых трафик может приниматься и отправляться. Вы можете дополнительно указать диапазон портов, например от 3000 до 3500, установив endPortполе (3500) в дополнение к port(3000).

Разрешить трафик из модулей с определенной меткой, существующих в другом пространстве имен

: Апиверсия networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация базы данных: подСелектор: {} Типы политик: - Вход входящий: - от: - namespaceSelector: Метки соответствия: приложение: подселектор демонстрационного приложения: метки соответствия: компонент: база данных

Политика гласит, что любой помеченный модуль component: databaseможет достигать всех модулей в databaseпространстве имен, если помечено его собственное пространство demo-appимен.

Вы можете разрешить трафик из всех модулей во внешнем пространстве имен, создав правило, которое включает только namespaceSelectorполе.

Явно разрешить весь трафик

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

: apiVersion networking.k8s.io/v1 вид: метаданные сетевой политики: имя: пространство имен сетевой политики: спецификация приложения: подСелектор: {} Типы политик: - Вход
 - Вход выхода: - {} Выход: - {}

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

Когда следует использовать сетевые политики

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

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

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

: Апиверсия networking.k8s.io/v1 вид: метаданные сетевой политики: имя: запретить-все пространство имен: спецификация приложения: подСелектор: {} Типы политик: - Вход
 - Выход

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

Краткие сведения

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

Рекомендуется настраивать сетевую политику для всех ваших модулей. Это защитит ваш кластер, поэтому разрешены только законные потоки трафика. Однако сетевые политики - это только одна часть безопасности Kubernetes: другие механизмы защиты, такие как RBAC и контексты безопасности Pod, также являются важными инструментами для повышения надежности вашей среды.