IPMan для Kubernetes: декларативное управление IPSec-туннелями через CRD и Libreswan

Организация защищенного сетевого взаимодействия между приложениями в кластере Kubernetes и корпоративными сервисами в изолированных центрах обработки данных традиционно требовала сложной ручной работы. Сетевым администраторам приходилось разворачивать внешние VPN-шлюзы, настраивать маршрутизацию на физических хостах кластера или поддерживать нестандартные прокси-серверы. Любое изменение IP-адресов удаленной подсети превращалось в рутинный тикет с согласованиями.

Опенсорсный проект IPMan от компании DialoHQ решает эту задачу в парадигме Cloud Native. Это специализированный оператор Kubernetes, который автоматизирует создание, маршрутизацию и мониторинг защищенных site-to-site туннелей IPSec непосредственно внутри кластера. В качестве криптографического ядра оператор использует проверенные инструменты стека IPsec (демон Charon и стек StrongSwan/Libreswan), управляя подсистемой трансформации пакетов Linux XFRM на узлах.

Архитектура оператора: декларативные ресурсы и самовосстановление

Работа оператора построена на концепции пользовательских ресурсов (Custom Resource Definitions, CRD):

• CharonGroup: определяет группу сетевых узлов, где поднимается демон шифрования и резервируется внешний сетевой интерфейс (hostNetwork: true). При этом сами рабочие поды приложений могут находиться на любых других узлах кластера.
• IPSecConnection: описывает параметры конкретного VPN-соединения — удаленный IP-адрес шлюза, параметры фаз IKE и ESP, используемые шифры, локальные и удаленные диапазоны подсетей.
• Пулы адресов (IP Pools): оператор выделяет изолированные диапазоны IP-адресов для сервисов, что позволяет внешним файрволам точно знать, какие поды обращаются к внутренней инфраструктуре.
• Встроенное самовосстановление (Self-healing): механизм отслеживания состояния узлов Dead Peer Detection (DPD) с политикой restart автоматически переподнимает туннель при кратковременных обрывах связи у интернет-провайдера.

Манифест соединения IPSecConnection

Вся конфигурация защищенного соединения описывается декларативным YAML-файлом, который сохраняется в Git-репозитории платформы и применяется через стандартный инструмент kubectl:

apiVersion: ipman.dialo.ai/v1
kind: IPSecConnection
metadata:
  name: corporate-datacenter-vpn
  namespace: ipman-system
spec:
  name: "corp-dc-tunnel"
  # Адреса локального и удаленного шлюзов
  remoteAddr: "198.51.100.10"
  remoteId: "198.51.100.10"
  localAddr: "203.0.113.5"
  localId: "203.0.113.5"
  # Ссылка на секрет с общим ключом (Pre-Shared Key)
  secretRef:
    name: "vpn-psk-secret"
    namespace: ipman-system
    key: "preSharedKey"
  groupRef:
    name: "primary-charon-group"
    namespace: ipman-system
  # Спецификация дочерних подсетей туннеля
  children:
    datacenter-subnet:
      name: "dc-network"
      remoteSubnets:
        - "10.50.0.0/16"
      localSubnets:
        - "10.244.0.0/16"
      dpdAction: "restart"

Секретный ключ авторизации извлекается из стандартного Kubernetes Secret, исключая хранение паролей в открытом виде.

Направление трафика сервиса в защищенный туннель

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-service
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: billing
  template:
    metadata:
      labels:
        app: billing
      annotations:
        # Автоматическая маршрутизация трафика пода через созданный туннель
        ipman.dialo.ai/childName: "datacenter-subnet"
        ipman.dialo.ai/poolName: "primary-pool"
    spec:
      containers:
        - name: app
          image: internal-registry.example.com/billing:v2.4
          ports:
            - containerPort: 8080

Сетевой агент оператора перехватывает запуск подов с аннотацией и автоматически привязывает их исходящие пакеты к виртуальному интерфейсу XFRM.

Практическая ценность для команд эксплуатации

Внедрение IPMan переводит управление корпоративными VPN-каналами в парадигму GitOps. Изменения сетевых политик, ротация ключей шифрования и добавление новых удаленных офисов происходят через стандартные пулреквесты в репозиторий инфраструктуры. Оператор совместим с популярными сетевыми плагинами (Cilium, Calico, Flannel), позволяя организовать надежный и прозрачный защищенный периметр без закупки дорогих проприетарных шлюзов.