Эксперименты с ClusterNetworkPolicy в GKE

Стандартные Network Policies ограничивают применение правил уровнем пространства имен, в то время как ClusterNetworkPolicy (CNP) позволяет применять детализированные сетевые политики ко всему кластеру. Используя CNP, вы можете легко масштабировать политики безопасности и управления. Недавно я поэкспериментировал с этой функцией в Google Kubernetes Engine (GKE) и лично убедился в ее преимуществах.

В этой статье мы рассмотрим использование CNP для управления трафиком к LLM и кластеру. Если вы хотите сразу перейти к практической лабораторной работе, ознакомьтесь с этим Codelab: Secure AI Inference Workloads with GKE ClusterNetworkPolicy.

Как работает CNP

CNP использует трехуровневую модель потока с проверкой приоритетов:

• Уровень администратора (высший приоритет): администратор кластера принудительно задает обязательные правила безопасности, которые невозможно обойти (например, блокировку доступа к метаданным).

Уровень администратора (высший приоритет): администратор кластера принудительно задает обязательные правила безопасности, которые невозможно обойти (например, блокировку доступа к метаданным).

• Уровень сетевых политик (средний приоритет): стандартные политики на уровне пространств имен, управляемые командами приложений для контроля входящего и исходящего трафика их микросервисов.

Уровень сетевых политик (средний приоритет): стандартные политики на уровне пространств имен, управляемые командами приложений для контроля входящего и исходящего трафика их микросервисов.

• Базовый уровень (низший приоритет): администратор кластера устанавливает резервные значения по умолчанию (например, политику запрета по умолчанию для всех пространств имен).

Базовый уровень (низший приоритет): администратор кластера устанавливает резервные значения по умолчанию (например, политику запрета по умолчанию для всех пространств имен).

Пример шаблона проектирования

Цель эксперимента в Codelab — ограничить трафик к пространству имен LLM, разрешить доступ только авторизованным клиентам и предотвратить доступ к API метаданных в масштабе всего кластера, за исключением порта DNS 53. Для этого используются следующие службы:

• Virtual Private Cloud (VPC): обеспечивает частную сеть, подсети для подов и служб, а также безопасный исходящий трафик через Cloud NAT.

Virtual Private Cloud (VPC): обеспечивает частную сеть, подсети для подов и служб, а также безопасный исходящий трафик через Cloud NAT.

• TPU v5e: высокоэффективное аппаратное обеспечение ускорителей (топология 2x2), выполняющее оптимизированный вывод моделей.

TPU v5e: высокоэффективное аппаратное обеспечение ускорителей (топология 2x2), выполняющее оптимизированный вывод моделей.

• GKE: управляемая платформа Kubernetes, работающая на базе GKE Dataplane V2 (eBPF) для обеспечения многоуровневых сетевых политик.

GKE: управляемая платформа Kubernetes, работающая на базе GKE Dataplane V2 (eBPF) для обеспечения многоуровневых сетевых политик.

• Gemma 4: легкая открытая модель, обслуживаемая с помощью vLLM в качестве конфиденциальной рабочей нагрузки ИИ.

Gemma 4: легкая открытая модель, обслуживаемая с помощью vLLM в качестве конфиденциальной рабочей нагрузки ИИ.

• ClusterNetworkPolicy (CNP): политики уровня кластера, позволяющие администраторам внедрять обязательные защитные меры на уровне администратора и базовом уровне во всех пространствах имен.

ClusterNetworkPolicy (CNP): политики уровня кластера, позволяющие администраторам внедрять обязательные защитные меры на уровне администратора и базовом уровне во всех пространствах имен.

• NetworkPolicies: стандартные правила на уровне пространств имен, позволяющие разработчикам предоставлять доступ авторизованным клиентам.

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

• Cloud Logging / GKE Network Policy Logging: фиксирует вердикты по пакетам в реальном времени (разрешено/запрещено) и журналы аудита политик.

Cloud Logging / GKE Network Policy Logging: фиксирует вердикты по пакетам в реальном времени (разрешено/запрещено) и журналы аудита политик.

Сборка воедино: обзор настройки

Настройка этой среды начинается с создания собственной инфраструктуры частной сети и развертывания кластеров с поддержкой TPU:

• Пользовательский VPC и Cloud NAT: создание пользовательского VPC с выделенной подсетью, в которой размещаются основные узлы, а также вторичными диапазонами IP-адресов CIDR для подов GKE (10.20.0.0/16) и служб (10.30.0.0/20). Cloud Router и Cloud NAT настроены для обработки безопасного исходящего трафика узлов при одновременной блокировке входящего доступа из интернета.

Пользовательский VPC и Cloud NAT: создание пользовательского VPC с выделенной подсетью, в которой размещаются основные узлы, а также вторичными диапазонами IP-адресов CIDR для подов GKE (10.20.0.0/16) и служб (10.30.0.0/20). Cloud Router и Cloud NAT настроены для обработки безопасного исходящего трафика узлов при одновременной блокировке входящего доступа из интернета.

• Кластер GKE Standard: развертывание стандартного кластера GKE под управлением GKE Dataplane V2 (ADVANCED_DATAPATH). GKE Dataplane V2 выступает в качестве основного компонента, который использует технологию eBPF «под капотом» для динамического применения как стандартных политик, так и политик уровня кластера.

Кластер GKE Standard: развертывание стандартного кластера GKE под управлением GKE Dataplane V2 (ADVANCED_DATAPATH). GKE Dataplane V2 выступает в качестве основного компонента, который использует технологию eBPF «под капотом» для динамического применения как стандартных политик, так и политик уровня кластера.

• Выделенный пул узлов TPU v5e: подготовка пула узлов с машинами ct5lp-hightpu-4t, организованными в срез топологии 2x2. Узлы имеют специальное ограничение (taint) (google.com/tpu=present:NoSchedule), гарантирующее, что на них будут запускаться только рабочие нагрузки ускорителей.

Выделенный пул узлов TPU v5e: подготовка пула узлов с машинами ct5lp-hightpu-4t, организованными в срез топологии 2x2. Узлы имеют специальное ограничение (taint) (google.com/tpu=present:NoSchedule), гарантирующее, что на них будут запускаться только рабочие нагрузки ускорителей.

• Развертывание рабочей нагрузки Gemma 4: изоляция подов путем создания трех отдельных пространств имен: gemma-llm (уровень: ai-core): обслуживает легкую модель Gemma 4 с использованием высокопроизводительного ядра vllm/vllm-tpu:latest на порту 8000. client-ns (уровень: app-frontend): запускает авторизованный чат-клиент, который должен отправлять запросы к модели. untrusted-tenant (уровень: untrusted): представляет неавторизованный контейнер зондирования, имитирующий вредоносный клиент.

Развертывание рабочей нагрузки Gemma 4: изоляция подов путем создания трех отдельных пространств имен:

• gemma-llm (уровень: ai-core): обслуживает легкую модель Gemma 4 с использованием высокопроизводительного ядра vllm/vllm-tpu:latest на порту 8000.
• client-ns (уровень: app-frontend): запускает авторизованный чат-клиент, который должен отправлять запросы к модели.
• untrusted-tenant (уровень: untrusted): представляет неавторизованный контейнер зондирования, имитирующий вредоносный клиент.

Защита LLM и метаданных: пошаговый разбор кода

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

Шаг 1: Установка режима нулевого доверия (базовый уровень)

Чтобы заблокировать весь неавторизованный входящий трафик в масштабе кластера, администратор кластера применяет ClusterNetworkPolicy на базовом уровне. Этот уровень служит резервной защитной сеткой.

Как это работает

• Определение приоритета: параметр tier: Baseline размещает эту политику в самом низу цепи оценки GKE, а значение priority: 1000 упорядочивает ее внутри этого уровня. Она обрабатывает только тот трафик, который не соответствует ни одному правилу на более высоких уровнях.

Определение приоритета: параметр tier: Baseline размещает эту политику в самом низу цепи оценки GKE, а значение priority: 1000 упорядочивает ее внутри этого уровня. Она обрабатывает только тот трафик, который не соответствует ни одному правилу на более высоких уровнях.

• Глобальная цель: Указание subject.namespaces: {} гарантирует, что этот резервный вариант применяется глобально ко всем подам в каждом пространстве имен.

Глобальная цель: Указание subject.namespaces: {} гарантирует, что этот резервный вариант применяется глобально ко всем подам в каждом пространстве имен.

• Исключение для изоляции DNS: Первое правило входящего трафика принимает входящий DNS-трафик по портам TCP и UDP 53. Без этого явного исключения разрешение DNS в масштабе кластера завершилось бы сбоем.

Исключение для изоляции DNS: Первое правило входящего трафика принимает входящий DNS-трафик по портам TCP и UDP 53. Без этого явного исключения разрешение DNS в масштабе кластера завершилось бы сбоем.

• Резервное отклонение: Второе правило сопоставляется с любой попыткой входящего подключения между подами и отбрасывает ее. На этом этапе пространствам имен client-ns и untrusted-tenant заблокирован доступ к Gemma.

Резервное отклонение: Второе правило сопоставляется с любой попыткой входящего подключения между подами и отбрасывает ее. На этом этапе пространствам имен client-ns и untrusted-tenant заблокирован доступ к Gemma.

Шаг 2: Делегирование доступа разработчикам (уровень networkpolicy)

При активном базовом запрете по умолчанию (default-deny) команда разработчиков приложения, управляющая gemma-llm, может безопасно делегировать доступ легитимным клиентам. Они определяют стандартную NetworkPolicy в рамках пространства имен, чтобы разрешить входящий трафик на порт 8000 от подов rag-agent в пространстве имен client-ns.

Как это работает

• Контроль разработчика: Этот ресурс находится в пространстве имен gemma-llm и управляется напрямую разработчиком, что соответствует ориентации GKE на операционное разделение.

Контроль разработчика: Этот ресурс находится в пространстве имен gemma-llm и управляется напрямую разработчиком, что соответствует ориентации GKE на операционное разделение.

• Сопоставление со средним приоритетом: Стандартные Kubernetes NetworkPolicies сопоставляются напрямую с уровнем NetworkPolicy. Поскольку этот уровень оценивается до базового уровня, входящие TCP-пакеты от авторизованного клиента на порт 8000 соответствуют этому правилу и немедленно принимаются.

Сопоставление со средним приоритетом: Стандартные Kubernetes NetworkPolicies сопоставляются напрямую с уровнем NetworkPolicy. Поскольку этот уровень оценивается до базового уровня, входящие TCP-пакеты от авторизованного клиента на порт 8000 соответствуют этому правилу и немедленно принимаются.

• Блокировка по остаточному принципу: Подключения, исходящие из пространства имен untrusted-tenant, не соответствуют этому правилу, переходят на базовый уровень и отбрасываются.

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

Шаг 3: Обеспечение глобальных средств защиты исходящего трафика (уровень администратора)

По умолчанию поды могут отправлять запросы к локальному для ссылки серверу метаданных Compute Engine в GKE (169.254.169.254). Эти запросы раскрывают метаданные экземпляра и потенциально токены сервисных аккаунтов с высоким уровнем привилегий. Чтобы ограничить это, администратор кластера применяет средства защиты исходящего трафика на самом верхнем уровне в иерархии GKE.

Как это работает

• Приоритет уровня администратора: Развертывание этой политики на уровне администратора гарантирует, что она оценивается первой, а приоритет 10 упорядочивает ее в рамках этого уровня. GKE обрабатывает эту политику до стандартных NetworkPolicies и базовых правил.

Приоритет уровня администратора: Развертывание этой политики на уровне администратора гарантирует, что она оценивается первой, а приоритет 10 упорядочивает ее в рамках этого уровня. GKE обрабатывает эту политику до стандартных NetworkPolicies и базовых правил.

• Контролируемое делегирование: Правила delegate-all-ingress и delegate-other-egress имеют директиву action: Pass, которая предписывает обработчику перенаправлять оценку на следующий уровень для остального внутрикластерного трафика.

Контролируемое делегирование: Правила delegate-all-ingress и delegate-other-egress имеют директиву action: Pass, которая предписывает обработчику перенаправлять оценку на следующий уровень для остального внутрикластерного трафика.

• Неприкокосновенное средство защиты: Когда любой под пытается запросить 169.254.169.254/32 на не-DNS портах, запрос соответствует правилу block-metadata-server-global и отбрасывается. Поскольку это отбрасывание происходит на верхнем уровне администратора, его нельзя обойти или переопределить, даже если разработчик пространства имен развернет политику исходящего трафика allow-all.

Неприкокосновенное средство защиты: Когда любой под пытается запросить 169.254.169.254/32 на не-DNS портах, запрос соответствует правилу block-metadata-server-global и отбрасывается. Поскольку это отбрасывание происходит на верхнем уровне администратора, его нельзя обойти или переопределить, даже если разработчик пространства имен развернет политику исходящего трафика allow-all.

Проверка с помощью Observability для GKE

Проверка и аудит политик безопасности выполняются просто благодаря встроенным возможностям телеметрии GKE Dataplane V2:

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

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

• Сетевое логирование GKE и Cloud Logging: Автоматически экспортирует структурированную телеметрию соединений и вердикты применения политик напрямую в Cloud Logging. Команды могут фильтровать решения политик и настраивать оповещения по ним, используя такие атрибуты, как disposition="deny", пространства имен источника/назначения и jsonPayload.policies[0].name, для поддержания соответствия требованиям аудита и расследования заблокированных попыток подключения.

Сетевое логирование GKE и Cloud Logging: Автоматически экспортирует структурированную телеметрию соединений и вердикты применения политик напрямую в Cloud Logging. Команды могут фильтровать решения политик и настраивать оповещения по ним, используя такие атрибуты, как disposition="deny", пространства имен источника/назначения и jsonPayload.policies[0].name, для поддержания соответствия требованиям аудита и расследования заблокированных попыток подключения.

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

Следующие шаги

Погрузитесь глубже и найдите дополнительную информацию об этих функциях:

• ClusterNetworkPolicy в GKE: Баланс контроля и автономности для ваших микросервисов

ClusterNetworkPolicy в GKE: Баланс контроля и автономности для ваших микросервисов

• Настройка GKE ClusterNetworkPolicy

Настройка GKE ClusterNetworkPolicy

Хотите задать вопрос, узнать больше или поделиться мнением? Свяжитесь со мной на LinkedIn!

• Разработчики и практики