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

Read more

«Kubernetes стал стандартом для контейнерных приложений, но стандартные настройки «из коробки» далеки от идеала безопасности. В отчётах CIS Benchmark содержится более 300 рекомендаций. Без автоматизации ручная проверка занимает недели. При этом многие уязвимости — это просто неправильно выставленные флаги или забытые политики. Злоумышленники сканируют интернет-кластеры и находят открытые порты, анонимный доступ, избыточные права. Наша задача — системно закрыть эти риски, сохранив работоспособность.» Read more

Инструкция по установке и настройке агентов Kaspersky Container Security (KCS) Общие сведения. Агенты KCS работают как контейнеризованные приложения на всех узлах кластера, который нужно защищать. Есть два типа агентов: csp-kube-agent для защиты кластера и csp-node-agent для защиты узлов. Они объединяются в группы агентов, и для каждого кластера создаётся отдельная группа. Способы установки агентов. Агенты можно установить двумя основными способами. Первый – через веб-интерфейс с автоматической генерацией YAML-инструкции. Второй – с помощью Helm Chart, скачивая конфигурационный файл values-agents.yaml. Перед установкой агентов обязательно нужно создать группу агентов в веб-интерфейсе. Пошаговая инструкция по установке.

• Создайте группу агентов в веб-интерфейсе. Перейдите в раздел Components – Agents, нажмите Add agent group.
• На вкладке General заполните параметры. Group name – имя группы, рекомендуется называть по имени кластера, при переустановке всегда проверяйте, что имя соответствует текущему кластеру. Description – описание, можно оставить без изменений. Orchestrator – тип оркестратора, должен соответствовать используемой платформе, проверьте это. Namespace – пространство имён для установки агентов, это ключевой параметр, оно должно существовать в кластере на момент запуска агентов, по умолчанию kcs-agents. KCS registry – URL реестра, где находятся образы для установки агентов, обязательно проверьте адрес, логин и пароль для доступа к реестру.
• На вкладке Node monitoring настройте мониторинг. Network connections monitoring – мониторинг сетевых соединений. Container processes monitoring – мониторинг процессов внутри контейнеров. File threat protection – защита от файловых угроз, здесь нужно указать URL для обновления антивирусных баз и при необходимости прокси-сервер, по умолчанию базы обновляются из облака Kaspersky. Отключение ненужных функций мониторинга снижает нагрузку на узлы. После заполнения нажмите Save. После сохранения на вкладке Deployment data появятся Deployment token – уникальный идентификатор для подключения агента к серверу, и YAML-инструкция для развёртывания агентов в кластере. Установка агентов через веб-интерфейс (YAML). Скопируйте YAML-инструкцию с вкладки Deployment data или скачайте как файл. Примените инструкцию в кластере командой kubectl apply -f <файл> -n , где namespace – то же пространство имён, что указано при создании группы. Инструкция автоматически обновляется при изменении TLS-сертификатов, URL реестра, учётных данных и SIEM-интеграции. Установка агентов через Helm Chart. Этот способ удобен для автоматизации. Скачайте конфигурационный файл values-agents.yaml через OpenAPI с помощью curl: curl -X 'GET' '{{kcs_domain}}/api/v1/integrations/agent-group/{{agentGroupId}}/values' -H 'accept: application/x-yaml' -H 'Tron-Token: {{token}}' -o values-agents.yaml, где agentGroupId – UUID группы агентов, token – API-токен пользователя. Затем установите агенты с помощью Helm: helm install kcs-agents . --create-namespace --namespace kcs-agents --values values-agents.yaml --set ... (дополнительные параметры). Проверка после установки. После установки рекомендуется проверить статус агентов в разделе Components – Agents веб-интерфейса, убедиться, что все узлы кластера отображаются как защищённые, и проверить работу политик среды выполнения (Runtime policies). Полезные ссылки на официальную документацию Kaspersky Container Security: support.kaspersky.com, раздел по установке агентов – support.kaspersky.com/ca/container-security/2.3/300161, создание группы агентов – support.kaspersky.com/ca/container-security/2.3/303578, установка через Helm – support.kaspersky.com/container-security/2.3/303393.

Аналитическая записка: Сетевая безопасность кластеров Kubernetes Содержание 1. Введение 2. Архитектура сети и пути прохождения трафика 2.1. Трафик Pod‑to‑Pod 2.2. Трафик через Service 2.3. Трафик извне через Ingress 3. Модель угроз и механизмы защиты 4. Основные принципы защиты 5. Реализация сетевой микросегментации 5.1. Cilium 5.2. Calico 5.3. Antrea 5.4. Сравнение Cilium и Calico 5.5. Как Cilium меняет картину трафика 5.6. Постоянный мониторинг и аудит 6. Коммерческие решения для усиления защиты 6.1. Palo Alto CN-Series 6.2. Platform V Synapse Service Mesh (российское решение) 6.3. Сравнительная таблица: усиление Cilium 7. Дополнительные средства безопасности и управления политиками 7.1. Kaspersky Container Security 7.2. PT Container Security 7.3. Luntry 7.4 Сравнительная таблица: дополнительные средства безопасности (не микросегментация) 8. Заключение 9. Источники 1. Введение Основная проблема сетевой безопасности Kubernetes связана с тем, что изначально поды не изолированы друг от друга. Если специально не настроить сетевые политики, один под может обращаться к другим подам, внутренним API, базам данных и внешним ресурсам. Поэтому компрометация даже одного контейнера может стать отправной точкой для дальнейшего перемещения по кластеру. На практике это означает, что стандартной сетевой конфигурации Kubernetes недостаточно для критичных систем. Необходимо явно определить, какие сервисы могут взаимодействовать между собой, какие подключения разрешены наружу и кто имеет доступ к API Kubernetes. Сетевая связность и микросегментация – это разные задачи. CNI (Container Network Interface) – это интерфейс и набор механизмов, через которые сетевой плагин подключает Pod к сети, настраивает его сетевое окружение и реализует сетевой datapath. Поддержка и применение NetworkPolicy зависят от конкретного сетевого плагина. Если в кластере не заданы сетевые политики, наличие CNI само по себе не означает, что фронтенд не сможет обратиться к платёжному сервису или базе данных. Модель доступа нужно прописать явно. На практике базовая микросегментация в Kubernetes реализуется с использованием сетевых политик, применение которых обеспечивает выбранный CNI. В качестве вариантов реализации могут рассматриваться Cilium и Calico. Дополнительные средства безопасности, сервисная сетка и NGFW решают смежные задачи и могут использоваться совместно с CNI. Переход к модели Zero Trust лучше выполнять поэтапно. Сначала необходимо собрать данные о взаимодействии сервисов, затем внедрить политики для отдельных бизнес-доменов и только после проверки перевести их в режим блокировки. Для крупного кластера этот процесс может занять несколько месяцев; точный срок зависит от числа сервисов, качества документации и зрелости процессов эксплуатации. Здесь мы хотим системно описать сетевые угрозы в Kubernetes, показать, как они выглядят в реальности и предложить работающие способы защиты. Основной упор – на подходы, которые применимы в любом окружении. Отдельно указаны решения, доступные на российском рынке. 2. Архитектура сети и пути прохождения трафика Чтобы понять, где и как применять микросегментацию, полезно сначала рассмотреть сеть без сетевых политик, а затем тот же путь с включёнными ограничениями. Рисунки 1–3 ниже показывают базовую связность: CNI установлен и работает, но политики доступа не заданы. Это состояние до внедрения микросегментации. Ниже рассмотрены три основных сценария, которые покрывают подавляющее большинство случаев: - трафик между подами (Pod-to-Pod); - трафик через Service (балансировка нагрузки); - трафик извне через Ingress. Другие возможные сценарии (например, межнеймспейсовое взаимодействие, маршрутизация через NAT, трафик между кластерами) являются комбинациями или вариациями описанных и не требуют отдельного рассмотрения. При необходимости они могут быть реализованы с использованием тех же механизмов политик, которые описаны для базовых сценариев. 2.1. Трафик Pod‑to‑Pod Основные понятия: Pod (под) – группа контейнеров, работающих вместе и разделяющих общее сетевое пространство. veth – виртуальный сетевой интерфейс, который соединяет под с хостом. CNI (Container Network Interface) – интерфейс и набор механизмов для подключения подов к сети. Фактическая реализация политик зависит от плагина. eBPF – технология, позволяющая встраивать логику обработки пакетов в ядро Linux. Используется некоторыми CNI для фильтрации трафика. Как это работает: Пакет из пода А выходит через виртуальный интерфейс и попадает в сетевой стек ноды. Поскольку сетевые политики не заданы, CNI-плагин пропускает пакет без ограничений. Пакет идёт либо напрямую к поду на той же ноде, либо, если целевой под на другой ноде, уходит через физический интерфейс – через overlay-сеть (VXLAN) или прямую маршрутизацию. На ноде-получателе пакет также не встречает ограничений – CNI доставляет его в целевой под без проверок. Весь путь пакета происходит без применения сетевых политик. Особый случай: если под запущен с hostNetwork: true, он переводится в сетевой namespace узла. Применение стандартной NetworkPolicy к такому трафику зависит от CNI и не должно считаться гарантированным. Для защиты подобных подов необходимо отдельно контролировать сетевой доступ к узлу и использование hostNetwork с помощью host-level политик (если они поддерживаются CNI) или других средств. Рис. 1 Базовая схема обмена данными между подами: CNI обеспечивает связность, но сетевые политики не ограничивают взаимодействие 2.2. Трафик через Service Service в Kubernetes – это абстракция, которая даёт стабильный IP-адрес (ClusterIP) для доступа к группе подов. Как это работает: Клиентский под отправляет запрос на ClusterIP-адрес Service. Запрос перехватывается механизмом балансировки. Service реализуется kube-proxy либо механизмом, предоставляемым CNI. В зависимости от выбранной реализации могут использоваться различные механизмы datapath, включая iptables, IPVS или eBPF. Балансировщик подменяет адрес назначения на IP-адрес одного из рабочих подов (DNAT). Поскольку сетевые политики не заданы, пакет свободно направляется выбранному поду-бэкенду без проверок. Таким образом, в отличие от сценария Pod-to-Pod, где трафик идёт напрямую от пода к поду, здесь трафик сначала поступает на абстракцию Service (ClusterIP), затем балансируется на один из подов, и только после этого доставляется к приложению. Это обеспечивает единую точку входа для внешних запросов и балансировку нагрузки. В классическом Kubernetes с iptables DNAT происходит до применения политик, поэтому политики пишутся для подов-бэкендов, а не для ClusterIP. При использовании CNI с заменой kube-proxy порядок может быть более гибким. Рис. 2 Базовая схема доступа к сервису через Service 2.3. Трафик извне через Ingress Ingress – это точка входа для внешних HTTP/HTTPS-запросов в кластер. Как это работает: Внешний запрос сначала попадает на балансировщик нагрузки (если он есть), затем на Ingress-контроллер. Ingress-контроллер, который в зависимости от конфигурации может выполнять TLS termination, маршрутизацию по host/path и дополнительные L7-проверкиЛф. Внутренние сетевые политики не применяются, поэтому после Ingress доступ к подам не ограничивается. Многослойный подход – проверка на уровне пода, на уровне сети ноды, на уровне приложения и на границе кластера – даёт более надёжную защиту, чем любой отдельный механизм. Однако в базовой конфигурации внутренний слой (NetworkPolicy) отсутствует. Рис. 3 Базовая схема внешнего доступа через Ingress и Service 3. Модель угроз и механизмы защиты Ниже – основные угрозы для Kubernetes-кластеров с точки зрения сетевой безопасности. Вероятность и влияние указаны в общем виде, в каждой конкретной среде они могут отличаться. Угроза Описание Механизмы защиты Горизонтальное перемещение Получив доступ к одному поду, злоумышленник перебирается к соседним – базам данных, API, метрикам Zero Trust, запрет всего по умолчанию, сегментация по неймспейсам и меткам через сетевые политики L7-атаки Через открытый порт посылаются запрещённые HTTP-запросы (например, DELETE /admin) – L3/L4-политики их не видят L7-фильтрация через расширенные сетевые политики (например, CiliumNetworkPolicy), для бинарных протоколов L3/L4 + mTLS (при использовании сервисной сетки) Исходящий трафик (Egress) Под уходит в интернет или на C&C-серверы, выносит данные Egress-политики, FQDN-правила, контроль DNS, Egress Gateway (при наличии) DNS-туннелирование Данные передаются через DNS-запросы, отследить трудно Разрешаем DNS-запросы только к CoreDNS, запрещаем внешние резолверы, ограничиваем скорость Уязвимости Ingress CVE-2025-1974 позволяет выполнить код на контроллере и украсть секреты Регулярные обновления, ограничение доступа к webhook, аудит аннотаций, WAF на границе Доступ к API-серверу Скомпрометированный под с широкими правами может управлять кластером Основной контроль – RBAC; сетевая блокировка только через whitelist на порт 443 (как исключение) Доступ к metadata-сервисам Под может получить облачные токены через AWS IMDS Блокировка 169.254.169.254 через Egress-политики, использование IMDSv2, IRSA Перехват трафика между нодами Трафик между нодами не шифруется. Шифрование (WireGuard) защищает только межнодовой трафик, внутри ноды – нет Шифрование между нодами (WireGuard/IPsec) + при необходимости mTLS внутри ноды (сервисная сетка) Уязвимости самого CNI Дыры в плагине, позволяющие обойти политики Регулярное обновление CNI (каждые 2–3 недели) Обход через hostNetwork Под запущен с hostNetwork: true и может обходить стандартные сетевые политики Использование host-level политик (если поддерживаются CNI), контроль hostNetwork через Pod Security Standards, ограничение доступа к узлу 4. Основные принципы защиты Основные рекомендации по настройке безопасности сети в Kubernetes следующие. Zero Trust: ничего не разрешаем по умолчанию, каждое разрешение прописываем явно. Это касается и входящего, и исходящего трафика. Режим аудита: перед блокировкой включаем логирование, собираем статистику 1–2 недели, корректируем правила и только потом включаем блокировки. Если сразу заблокировать – можно случайно уронить работающий сервис. Контроль исходящего трафика: разрешаем только то, куда подам действительно нужно ходить. Для внешних интеграций используем Egress Gateway, чтобы выдавать фиксированные IP. L7-фильтрация: проверяем не только IP и порты, но и то, что именно приходит в запросе. Для HTTP/gRPC используем расширенные сетевые политики (например, CiliumNetworkPolicy). Для баз данных – L3/L4 + mTLS. Шифрование между нодами: обеспечивает защиту трафика при переходе на другую ноду. Внутри одной ноды для защиты требуется mTLS (при использовании сервисной сетки). Pod Security Standards: это первый барьер – запрещаем подам использовать сеть ноды без необходимости, отключаем опасные capabilities. Защита API-сервера: основная защита – RBAC. Сетевые блокировки применяем только в виде whitelist-правил и только после аудита. DNS-безопасность: все DNS-запросы должны проходить через CoreDNS с кэшированием и ограничением скорости, внешние резолверы запрещаем. Наблюдаемость: собираем flow-логи через встроенные средства CNI (например, Hubble) или аналоги, чтобы понимать происходящее и быстро реагировать на аномалии. GitOps: храним все политики в Git, применяем через ArgoCD или FluxCD – это даёт версионность и аудит. Обновление CNI выполняется в соответствии с жизненным циклом поддерживаемых версий, security advisories и результатами проверки совместимости с Kubernetes и ядром Linux. Критические уязвимости требуют внепланового обновления 5. Реализация сетевой микросегментации 5.1. Cilium Cilium – CNI-плагин и платформа сетевой безопасности, использующая eBPF как основу datapath. Поддерживает стандартные Kubernetes NetworkPolicy и собственные расширенные политики (CiliumNetworkPolicy), позволяющие контролировать трафик на уровнях L3/L4 и L7 (HTTP, gRPC, DNS). Встроенный компонент Hubble обеспечивает наблюдаемость сетевых потоков. Дополнительные возможности включают Host Firewall, Egress Gateway и замену kube-proxy. Cilium использует eBPF для обработки сетевого трафика в ядре Linux, что позволяет уменьшить зависимость от традиционных цепочек iptables. Фактический эффект зависит от конфигурации datapath и характера нагрузки. L7-политики в Cilium реализуются с привлечением прокси-компонента (Envoy) для глубокой инспекции прикладного трафика. 5.2. Calico Calico – CNI с поддержкой Kubernetes NetworkPolicy и собственной расширенной моделью политик (GlobalNetworkPolicy). Поддерживает защиту узлов через Host Endpoints и host-политики. В зависимости от редакции и выбранного datapath доступны различные варианты обработки трафика (включая eBPF). Calico Open Source предоставляет базовые расширенные политики; коммерческая редакция Calico Enterprise добавляет дополнительные возможности управления и рекомендации политик. Оба решения (Cilium и Calico) поддерживают декларативную политику на основе идентификаторов workload и селекторов. Calico дополнительно предоставляет собственную модель GlobalNetworkPolicy, host endpoints и расширенные механизмы управления политиками. 5.3. Antrea Antrea – Kubernetes CNI, ориентированный на сетевую связность и политику внутри Kubernetes. Проект поддерживает стандартный NetworkPolicy и расширенные объекты, включая ClusterNetworkPolicy, FQDN-политики и Node NetworkPolicy. Технологически Antrea относится к той же группе решений, что Cilium и Calico. Подтверждённого канала коммерческой поставки и официальной поддержки в РФ при подготовке документа не выявлено, поэтому в основной список для российского заказчика он не включается. 5.4. Сравнение Cilium и Calico Критерий Cilium Calico (Open Source) Calico Enterprise Базовая технология eBPF (ядро Linux) IP-маршрутизация + iptables / eBPF (опционально) IP-маршрутизация + iptables / eBPF (опционально) Сетевой уровень политик L3/L4 и L7 (HTTP, gRPC, DNS) L3/L4, расширенные политики (GlobalNetworkPolicy) L3/L4, расширенные политики, рекомендации Идентификация в политиках По меткам (labels) и identity По меткам (labels), селекторам По меткам (labels), селекторам Балансировка нагрузки (Service) Встроенная, замена kube-proxy Отсутствует (используется kube-proxy) Отсутствует (используется kube-proxy) Service Mesh-функции Имеются возможности управления сервисным трафиком; отдельные механизмы взаимной аутентификации зависят от версии и конкретной конфигурации. Для полноценного service mesh могут использоваться отдельные решения Отсутствуют Отсутствуют Наблюдаемость Hubble (встроенный, сбор flow-логов) Flow logs (требуется настройка) Flow logs, рекомендации политик Шифрование между нодами WireGuard, IPsec IPsec, WireGuard IPsec, WireGuard Защита хоста (Host Firewall) Встроенный Host Firewall Host endpoints и host-политики Host endpoints, рекомендации Поддержка Windows Ограниченная Да (полноценная) Да (полноценная) Производительность при росте правил Зависит от конфигурации; использование eBPF позволяет снизить накладные расходы по сравнению с классическими iptables В режиме iptables может снижаться при большом числе правил; eBPF-режим даёт более предсказуемую производительность То же, что Open Source, плюс дополнительные оптимизации Поддержка BGP Да (через интеграцию) Да (нативная) Да (нативная) Уровень зрелости Активно развивается, CNCF Graduated Зрелое, проверенное решение Зрелое, корпоративное решение Сложность внедрения Высокая (требует понимания eBPF) Средняя (гибкий выбор datapath) Средняя/Высокая Ключевые различия (кратко) Архитектура. Calico строит сеть на основе классических механизмов Linux (iptables, IP-маршрутизация) с опциональной поддержкой eBPF. Cilium изначально построен на eBPF и работает на уровне ядра. Политики. Оба решения поддерживают декларативные политики на основе меток. Calico дополнительно предоставляет GlobalNetworkPolicy и host endpoints. Производительность. При росте числа сетевых правил iptables-решения (Calico в стандартном режиме) могут показывать снижение производительности; eBPF-режимы (Cilium, Calico eBPF) обеспечивают более предсказуемую производительность. Фактические показатели зависят от конфигурации и требуют проверки на целевой инфраструктуре. Наблюдаемость. У Cilium Hubble встроен «из коробки». Calico требует отдельной настройки flow logs. Service Mesh-функции. Cilium предлагает встроенные возможности управления сервисным трафиком без sidecar-прокси. Calico таких функций не имеет, но интегрируется с отдельными Service Mesh-решениями. Поддержка Windows. Calico – один из немногих CNI с полноценной поддержкой Windows-узлов. Рекомендации по выбору Сценарий Рекомендация Обоснование Высоконагруженные микросервисы, важна L7-фильтрация и наблюдаемость Cilium Встроенный Hubble, L7-политики, eBPF datapath Гетерогенные среды (Linux + Windows), гибридные облака Calico Поддержка Windows, BGP, зрелость Крупные кластеры, тысячи подов Оба решения (проверка на целевой инфраструктуре) eBPF-режимы в обоих решениях дают предсказуемую производительность Строгие требования безопасности и compliance Calico Enterprise Проверенная модель политик, host endpoints, рекомендации Нужны Service Mesh-функции без sidecar'ов Cilium Встроенные возможности управления сервисным трафиком Простота и предсказуемость Calico Open Source Более зрелое решение с понятной архитектурой Таким образом, выбор между Cilium и Calico зависит от конкретных требований: для высоконагруженных микросервисов с потребностью в L7-фильтрации и наблюдаемости предпочтительнее Cilium; для гетерогенных сред и строгих требований к безопасности – Calico (с учётом редакции). Окончательное решение следует принимать после пилотного проекта на реальной конфигурации кластера. 5.5. Как Cilium меняет картину трафика В отличие от «голого» Kubernetes, где весь трафик между подами разрешён по умолчанию, при использовании Cilium появляются точки контроля, где применяются политики безопасности. Ниже показаны те же три сценария, что и в разделе 2, но с включёнными механизмами защиты. На рисунке 4 изображён сценарий Pod-to-Pod с точками контроля. Трафик от Pod A проходит через ТОЧКУ КОНТРОЛЯ 1, где применяются политики L3/L4 и L7, затем маршрутизируется, шифруется между нодами и попадает на вторую ноду, где снова проверяется ТОЧКОЙ КОНТРОЛЯ 2, прежде чем попасть в Pod B. Рис. 4 Микросегментация обмена данными между подами с применением сетевых политик На рисунке 5 показан сценарий балансировки нагрузки через Service с точкой контроля. Запрос от клиентского пода проходит через Service, балансируется на бэкенд и проверяется ТОЧКОЙ КОНТРОЛЯ, где применяются NetworkPolicy и L7-фильтрация. Рис. 5 Доступ к сервису через Service с ограничениями, заданными сетевыми политиками На рисунке 6 изображён внешний запрос через Ingress с двумя точками контроля: первая – на границе кластера (Ingress-контроллер с TLS, WAF, L7-фильтрацией), вторая – внутри кластера (NetworkPolicy, проверяющая доступ к Pod'у приложения). Рис. 6 Внешний доступ через Ingress при наличии внутренних сетевых политик 5.6. Постоянный мониторинг и аудит После того как Cilium настроен и политики применены, работа не заканчивается. Сетевые взаимодействия в динамичной среде Kubernetes постоянно меняются: появляются новые сервисы, обновляются версии, меняются зависимости. Политики, которые работали месяц назад, могут стать неактуальными или даже начать блокировать легитимный трафик. Чтобы этого избежать, необходимо организовать непрерывный мониторинг сетевых потоков. В Cilium для этого используется компонент Hubble. Он собирает все flow-логи – кто к кому обращался, с каким портом, протоколом и с каким результатом (разрешено или заблокировано). На основе этих данных можно: - выявлять аномалии – например, неожиданные соединения между сервисами; - проверять, что политики работают корректно и не блокируют нужный трафик; - обнаруживать попытки несанкционированного доступа; - корректировать политики при изменении архитектуры приложений; - расследовать инциденты – видеть полную картину сетевых взаимодействий. Hubble также интегрируется с системами мониторинга (Prometheus, Grafana) и SIEM-решениями, что позволяет встроить наблюдение за сетевой безопасностью в общий контур управления инцидентами. Таким образом, внедрение Cilium – это не разовое действие, а процесс. Мониторинг и аудит должны стать частью регулярной эксплуатации, чтобы политики оставались актуальными, а кластер – защищённым. 6. Коммерческие решения для усиления защиты 6.1. Palo Alto CN-Series Это контейнеризированный межсетевой экран нового поколения (NGFW), который ставится поверх Cilium (или другого CNI). Принцип работы CN-Series CN-Series — это контейнеризированный межсетевой экран нового поколения (NGFW), который разворачивается в кластере Kubernetes с использованием нативных для Kubernetes механизмов — Pod'ов, Service, ConfigMap, DaemonSet и Helm-чартов. Он построен на распределённой архитектуре PAN-OS: плоскость управления (CN-MGMT) и плоскость обработки данных (CN-NGFW) разделены. Архитектура и компоненты CN-Series состоит из нескольких ключевых компонентов: CN-MGMT (management plane) — управляющий Pod, который работает как StatefulSet с постоянным хранилищем и доступен через Kubernetes Service. Отвечает за связь с Panorama, управление лицензиями, конфигурацию и координацию работы CN-NGFW Pod'ов. Обеспечивает отказоустойчивость: при сбое одного CN-MGMT Pod'а другой продолжает управлять существующими CN-NGFW Pod'ами. CN-NGFW (data plane) — Pod'ы, которые непосредственно обрабатывают и фильтруют трафик. Могут быть развёрнуты как DaemonSet (на каждой ноде) или как Kubernetes Service (общий пул). В режиме DaemonSet каждый экземпляр CN-NGFW Pod'а может обслуживать до 30 прикладных Pod'ов на одной ноде. Пара CN-MGMT Pod'ов может управлять до 30 CN-NGFW Pod'ов в кластере. PAN-CNI — специальный CNI-плагин, который перенаправляет трафик от прикладных Pod'ов в CN-NGFW Pod для проверки. Он автоматически настраивает сетевые интерфейсы прикладных Pod'ов и перенаправляет трафик в файрвол. CN-INIT — init-контейнер, который генерирует сертификаты для защищённого IPSec-взаимодействия между CN-MGMT и CN-NGFW Pod'ами. Panorama — внешняя система управления, которая подключается к кластеру через Kubernetes-плагин. Требуется для управления лицензиями, конфигурацией и мониторинга CN-Series. Kubernetes Plugin for Panorama — плагин, который собирает информацию о метках (labels), неймспейсах и сервисах из кластера в режиме, близком к реальному времени. На основе этих данных создаются тэги и объекты сервисов, которые затем используются в политиках безопасности для динамической адресации. Тэги автоматически передаются в CN-NGFW Pod'ы и могут использоваться в Dynamic Address Groups для контекстно-зависимых политик. Поток трафика (CNv1, DaemonSet) При развёртывании CN-Series как DaemonSet (CNv1): PAN-CNI-плагин перенаправляет трафик от прикладного Pod'а в CN-NGFW Pod на той же ноде. CN-NGFW Pod применяет политики безопасности: L3/L4-фильтрацию, App-ID (распознавание приложений), Threat Prevention (IPS, антивирус), URL-фильтрацию и TLS-инспекцию. После проверки трафик направляется к целевому Pod'у или покидает ноду через физический интерфейс. Политики безопасности могут быть контекстно-зависимыми: они используют метки Pod'ов, неймспейсы и сервисы, собранные Kubernetes-плагином Panorama. Варианты развёртывания CN-Series предлагает три варианта развёртывания, которые различаются способом организации плоскости обработки данных (CN-NGFW): CNv1 (DaemonSet) — файрвол на каждой ноде. Каждый экземпляр CN-NGFW Pod'а защищает прикладные Pod'ы на той же ноде. Подходит для кластеров с большими нодами и приложениями, чувствительными к задержкам. Короткий локальный маршрут, минимальная задержка, но требует ресурсов на каждой ноде. CNv2 (Kubernetes Service, общий пул) — CN-NGFW Pod'ы развёрнуты как Kubernetes Service с ReplicaSet и поддержкой Horizontal Pod Autoscaler (HPA). PAN-CNI-плагин создаёт VXLAN-туннель между интерфейсом прикладного Pod'а и ClusterIP-адресом CN-NGFW Service. Трафик направляется в общий пул CN-NGFW Pod'ов, где обрабатывается. Упрощает управление и позволяет автомасштабировать количество файрволов, но добавляет дополнительный hop и риск узкого места. CNv3 (изолированные инстансы, Kubernetes CNF) — отдельные изолированные экземпляры CN-NGFW для каждого сегмента (неймспейса, команды, приложения). Каждый сегмент получает собственный экземпляр файрвола с независимыми политиками. Отказ или нагрузка одного инстанса не влияют на другие. Подходит для корпоративных сред с требованиями мультиарендности и строгой изоляции. При необходимости дополнительной L7-инспекции и NGFW-функций CN-Series может использоваться поверх любого CNI (в том числе Cilium). Схема прохождения трафика Рисунок 7 — Схема прохождения трафика через Palo Alto CN-Series (CNv1, DaemonSet) Возможности: - App-ID – распознаёт приложения, включая базы данных, и применяет политики к конкретным типам трафика. - Threat Prevention – IPS, антивирус, защита от эксплойтов, блокировка C&C-трафика. - TLS-инспекция – расшифровывает и проверяет зашифрованный трафик. - URL-фильтрация – блокирует доступ к вредоносным сайтам. - Panorama – единая консоль для политик и логирования. Плюсы: глубокая защита от угроз. Минусы: для российских заказчиков могут быть проблемы с импортозамещением. 6.2. Platform V Synapse Service Mesh (российское решение) Российский сервис-меш на базе Istio и Envoy. Внесён в реестр отечественного ПО (№ 14193). Разработан СберТехом. Работает поверх любого CNI, включая Cilium. Возможности: - mTLS – шифрование и аутентификация между сервисами, в том числе внутри одной ноды. - Управление трафиком – маршрутизация, канареечные развёртывания, A/B-тесты. - Наблюдаемость – сквозная трассировка, метрики, логи. - Отказоустойчивость – таймауты, повторные попытки, защита от каскадных сбоев. - Авторизация на уровне сервисов. Как дополняет Cilium: - Cilium даёт сеть и политики, Synapse – mTLS, канарейки, трассировку. - Это опция, а не обязательный компонент. Если нужны только базовые L7-политики, Cilium справляется сам. Совместимость: с Cilium 1.13.x и выше, с Deckhouse, «Штурвалом», Nova. Когда выбирать: когда нужны mTLS, сложная маршрутизация, трассировка или российское происхождение. 6.3 Сравнительная таблица: усиление Cilium Критерий Cilium (базовый) + Palo Alto CN-Series + Platform V Synapse L3/L4-политики Да Да Да L7-фильтрация (HTTP/gRPC) Да Да (плюс App-ID) Да (плюс маршрутизация) Шифрование между нодами Да (WireGuard) Да (WireGuard) Да (WireGuard) Шифрование внутри ноды (mTLS) Нет Нет Да IPS / антивирус / Threat Prevention Нет Да Нет App-ID (распознавание приложений) Нет Да Нет URL-фильтрация Нет Да Нет TLS-инспекция Нет Да Нет Канарейки / A/B-тесты Нет Нет Да Сквозная трассировка Нет (только Hubble) Нет Да Управление трафиком Базовая L7-фильтрация Базовая L7-фильтрация Полноценная маршрутизация, retry, timeout Централизованное управление Hubble Panorama Kiali, Jaeger Сложность Высокая Высокая Высокая (дополнительный слой) Ресурсы Нет sidecar'ов Нет sidecar'ов Требует sidecar'ы Импортозамещение Open Source Ограничено Есть (реестр) 7. Дополнительные средства безопасности и управления политиками Эти решения не являются полноценной заменой CNI и Kubernetes NetworkPolicy, но могут дополнять сетевую защиту средствами runtime-контроля, анализа и автоматизации Важно: они не заменяют сетевые политики. 7.1. Kaspersky Container Security Решение от «Лаборатории Касперского» для безопасности контейнеров в рантайме. Что делает: - Инвентаризация ресурсов кластера. - Аудит конфигурации. - Сканирование образов на уязвимости. - Runtime-профили (контроль выполнения). - Сетевой мониторинг через eBPF (в том числе поверх Cilium). Плюсы: российское решение. 7.2. PT Container Security Российское решение от Positive Technologies. Что делает: - Сканирование образов, управление уязвимостями с PT Sandbox. - Мониторинг рантайма с гибкими правилами. - Управление безопасностью нескольких кластеров. - Интеграция с CI/CD и артифакториями. - Admission controller для контроля создаваемых объектов. Плюсы: в реестре ПО (№17884), сертифицировано ФСТЭК 7.3. Luntry Luntry – российское решение для безопасности Kubernetes, которое помогает анализировать реальные сетевые взаимодействия между сервисами. Для задачи микросегментации оно полезно тем, что может автоматически формировать и сопровождать сетевые политики на основе данных о трафике, а также выявлять избыточные связи между сервисами. Luntry можно использовать вместе с Cilium и Calico для упрощения управления политиками. Сравнительная таблица: дополнительные средства безопасности и управления политиками Критерий Kaspersky Container Security PT Container Security Luntry Сканирование образов Да Да Нет Аудит конфигурации Да Да Нет Runtime-профили Да Да Ограниченно Сетевой мониторинг (eBPF) Да Нет Да Admission controller Нет Да Нет Автоматизация политик Нет Нет Да Реестр ПО РФ Нет Да (№17884) Нет Сертификация ФСТЭК Совместим Да Нет 9. Заключение Сетевая безопасность в Kubernetes строится на нескольких уровнях, и каждый из них важен. Микросегментация не сводится к выбору одного инструмента – это комплексный подход к ограничению сетевых взаимодействий между рабочими нагрузками. Практическая архитектура микросегментации строится по уровням: - Сетевой уровень – CNI и сетевые политики (Cilium или Calico). Это основа, которая определяет, какие взаимодействия между подами разрешены, а какие запрещены. - Уровень узла – межсетевой экран хоста, контроль hostNetwork и служебных интерфейсов. Защищает саму ноду от несанкционированного доступа. - Уровень сервисов – шифрование (mTLS) и идентичность сервисов при использовании сервисной сетки (Platform V Synapse). Добавляет защиту на уровне приложений. - Граница кластера – Ingress/Gateway и межсетевой экран на границе (Palo Alto CN-Series или WAF). Контролирует входящий трафик извне. - Уровень эксплуатации – GitOps, аудит политик, наблюдаемость через Hubble (или аналоги) и регулярная проверка актуальности правил. Обеспечивает постоянный контроль и управляемость политик. Дополнительные слои (не микросегментация): Kaspersky Container Security, PT Container Security и Luntry не являются заменой CNI. Они решают задачи безопасности на других уровнях: сканирование образов, аудит конфигурации, мониторинг выполнения и автоматизация управления политиками. Ключевые принципы: - Для критичных Kubernetes-сред целесообразно применять принципы Zero Trust. На уровне сетевого взаимодействия это означает минимально необходимые разрешения, запрет неиспользуемых соединений и явное описание допустимого трафика. - Внедрять нужно постепенно: сначала режим наблюдения, потом разрешающие политики, затем блокировка. - Без наблюдаемости (Hubble, логи) защита не работает – вы не сможете проверить, что политики действительно применяются. - Все правила должны храниться в Git (GitOps) – это даёт версионность, аудит и упрощает совместную работу команд. - L7-фильтрация, проксирование и шифрование увеличивают вычислительную нагрузку и могут влиять на задержку и пропускную способность. Перед промышленным внедрением необходимо выполнить нагрузочное тестирование на целевой конфигурации» На текущем этапе Cilium представляется предпочтительным кандидатом при необходимости расширенных L7-политик, eBPF datapath и интегрированной сетевой наблюдаемости. Calico следует рассматривать как альтернативный вариант сетевого уровня, особенно при требованиях к GlobalNetworkPolicy, host endpoint policy, BGP и совместимости с существующей инфраструктурой. Окончательный выбор рекомендуется делать по результатам пилота. При необходимости mTLS и сервисной авторизации поверх выбранного CNI может использоваться Platform V Synapse Главный вывод: системная защита – это не разовое действие, а непрерывный процесс. Начинать стоит с самых важных для бизнеса сервисов, постепенно расширяя покрытие на остальные компоненты кластера. 10. Источники 1. Kubernetes Documentation – Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/ 2. Kubernetes Documentation – Services, kube-proxy and virtual IPs: https://kubernetes.io/docs/reference/networking/virtual-ips/ 3. Kubernetes Documentation – Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/ 4. Cilium Documentation – Architecture, Network Policy, Hubble and Host Firewall: https://docs.cilium.io/ 5. Calico Documentation – Network Policy and host endpoints: https://docs.tigera.io/calico/latest/ 6. Antrea Documentation: https://antrea.io/ 7. Kaspersky Container Security: https://support.kaspersky.ru/ 8. Positive Technologies PT Container Security: https://www.ptsecurity.com/ 9. Platform V Synapse: https://platformv.sbertech.ru/ 10. Luntry: https://luntry.ru/k8security