Микросегментация Kubernetes: практическая реализация Zero Trust с Cilium и Calico

Реализация модели Zero Trust через микросегментацию сети - это не маркетинговая концепция, а конкретные технические политики, которые контролируют трафик между отдельными рабочими нагрузками в Kubernetes. В этой статье вы получите готовые YAML-манифесты для Cilium и Calico, практическое сравнение инструментов и пошаговый план безопасного внедрения, который предотвращает lateral movement атак в вашем кластере.

Почему модель «доверенных зон» больше не работает в Kubernetes

Концепция «доверенной внутренней сети» стала главной уязвимостью в контейнерных средах. В кластерах Kubernetes с политиками по умолчанию allow all один скомпрометированный pod получает доступ ко всему кластеру. Это прямо противоречит принципам Zero Trust: «никому не доверяй, проверяй всё».

Как атакующие используют доверие внутри кластера

В реальных инцидентах безопасности злоумышленники, получив доступ к одному контейнеру, перемещаются между неймспейсами и подами, используя открытые сетевые порты. Механика lateral movement работает потому, что сетевые политики по умолчанию разрешают весь трафик. Например, уязвимость в веб-приложении frontend позволяет атакующему подключиться к базе данных backend через внутренний сетевой интерфейс, минуя внешние средства защиты.

Микросегментация как основа Zero Trust: от теории к практике

Микросегментация в контексте Kubernetes - это контроль трафика на уровне pod и service, а не на уровне узлов или VLAN. Ключевой сдвиг происходит в использовании Workload Identity вместо IP-адресов. Принцип deny by default с явным разрешением только необходимых соединений становится фундаментом безопасности.

Workload Identity: почему политики должны строиться на метках, а не на IP

IP-адресация в динамичной среде Kubernetes нестабильна: поды пересоздаются, масштабируются, их адреса меняются. Метки (labels) и селекторы становятся постоянными идентификаторами для политик безопасности. Workload Identity связывает pod с service account, аннотациями и другими атрибутами, создавая устойчивую основу для правил доступа. Например, политика может разрешать трафик от всех подов с меткой app=frontend к подам с меткой app=backend, независимо от их текущих IP-адресов.

Cilium vs Calico: выбираем инструмент для микросегментации

Сравнение Cilium и Calico для реализации Zero Trust фокусируется на возможностях создания политик на основе Workload Identity. Cilium использует eBPF для детального контроля на уровне приложений (L7), Calico предлагает проверенную микросегментацию L3-L4 с возможностью интеграции с Istio.

Cilium и eBPF: детальный контроль на уровне приложений (L7)

Технология eBPF позволяет Cilium фильтровать трафик по HTTP-методам, путям и заголовкам. CiliumNetworkPolicy может разрешать только POST-запросы к пути /api определенного сервиса, блокируя все остальные методы и пути. Это требует ядра Linux версии 4.9.17 или выше с поддержкой eBPF. Пример политики:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-api-access
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "POST"
          path: "/api/v1/*"

Calico: надежная и проверенная микросегментация L3-L4

Архитектура Calico основана на iptables/IPVS с возможностью работы в pure L3-режиме через BGP. GlobalNetworkPolicy и NetworkSet позволяют создавать сложные правила для всего кластера. Для контроля на уровне L7 Calico интегрируется с Istio через аннотации. NetworkPolicy в Calico:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Сравнительная таблица возможностей для Zero Trust:

Для детального сравнения CNI-плагинов, включая производительность и сложность настройки, обратитесь к нашему актуальному сравнению CNI-плагинов для Kubernetes в 2026 году.

Пошаговая реализация: от нуля до работающих политик

Предварительные требования: Kubernetes версии 1.16+ для NetworkPolicy, установленный CNI-плагин Cilium или Calico. Стратегия включает аудит существующего трафика с помощью Cilium Hubble или Calico Flow logs, составление матрицы доступа между микросервисами и поэтапное внедрение в non-critical неймспейсах.

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

Этот YAML-манифест CiliumNetworkPolicy изолирует базу данных, разрешая трафик только от backend-сервисов:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: db-isolation
spec:
  endpointSelector:
    matchLabels:
      app: postgres-db
      tier: database
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: backend-api
        tier: backend
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP
  egress: []
  description: "Разрешает подключение к PostgreSQL только от backend API"

Проверить применение политики можно командами kubectl get cnp или cilium-cli: cilium status --namespace production.

Пример политики для Calico: контроль доступа к API бэкенда

NetworkPolicy для Calico контролирует доступ к API, используя podSelector и namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-access-control
spec:
  podSelector:
    matchLabels:
      app: payment-api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
      namespaceSelector:
        matchLabels:
          env: production
    ports:
    - protocol: TCP
      port: 443
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

Политика применяется командой kubectl apply -f policy.yaml, проверяется через kubectl describe networkpolicy api-access-control.

Стратегия безопасного внедрения: как не сломать продакшен

План минимизации рисков при внедрении микросегментации:

1. Включите режим аудита (audit) в политиках перед применением блокирующих правил.
2. Начните с неймспейсов для тестирования и разработки, а не с production.
3. Используйте постепенное ужесточение: сначала разрешите весь трафик извне неймспейса, затем конкретизируйте правила на основе логов.
4. Подготовьте rollback-план - быстрый скрипт удаления всех NetworkPolicy в неймспейсе.

Мониторинг логов отклоненных пакетов в Cilium Hubble или Calico Flow logs показывает неучтенные зависимости между сервисами.

Для комплексного подхода к сетевой безопасности контейнеров, включая контроль iptables и минимизацию поверхности атаки, изучите наше пошаговое руководство по сетевой безопасности Docker и Kubernetes в 2026 году.

За пределами Kubernetes: микросегментация в гибридных и корпоративных средах

Основные вызовы включают интеграцию с виртуальными машинами, bare-metal серверами и сетевым оборудованием. Подходы: использование Calico для гибридных облаков с поддержкой BGP, sidecar-прокси Envoy для legacy-сервисов, API-шлюзы как точки применения политик. Концепция «единой плоскости управления» безопасностью объединяет правила для контейнеров и традиционной инфраструктуры.

Интеграция политик Kubernetes с корпоративным сетевым экраном

Скоординируйте NetworkPolicy внутри кластера с правилами на корпоративном NGFW. Используйте теги и аннотации pod для синхронизации политик. В сценарии, где pod обращается к корпоративной базе данных за пределами кластера, NetworkPolicy разрешает egress-трафик на определенный CIDR, а правило на firewall фильтрует подключения по сертификатам клиента или меткам безопасности.

Для развертывания защищенной инфраструктуры рассмотрите облачные решения, такие как Timeweb Cloud, которые предоставляют управляемый Kubernetes с интегрированными сетевыми политиками.

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

Конкретные результаты внедрения: сокращение поверхности для атак lateral movement на 80-90%, соответствие требованиям compliance стандартов PCI DSS и ISO 27001, упрощение аудита безопасности через декларативные правила. Дальнейшие шаги включают внедрение L7-политик для HTTP-трафика и автоматизацию генерации правил на основе Service Mesh. Безопасность становится свойством архитектуры, а не надстройкой.

Для полного понимания сетевого стека Kubernetes, от выбора CNI-плагина до диагностики проблем в продакшене, обратитесь к нашему практическому руководству по управлению трафиком в Kubernetes.