Вопрос или проблема
Я работаю в специальной хост-среде только с внешними IP и без внутренних подсетей. В среде действуют строгие правила межсетевого экрана, требующие явных правил для каждого входящего и исходящего соединения. Эти правила поддерживают только TCP/UDP, при этом протокол IP 4 не разрешен. Более того, я не могу запрашивать входящий доступ к определенным диапазонам IP; разрешен только входящий трафик с моего внешнего IP. Это делает невозможным разрешение трафика к serviceSubnet Kubernetes.
Вот настройки моей среды:
podSubnet: 10.244.0.0/16
serviceSubnet: 10.245.192.0/18
Я уже успешно обошел межсетевой экран для podSubnet с помощью зашифрованных соединений через Calico + WireGuard или Cilium + WireGuard. Это позволяет подам обмениваться данными, обходя межсетевой экран.
Однако проблема сохраняется для serviceSubnet, так как трафик в этом диапазоне не зашифрован, что вызывает проблемы с подключением. Например, при запуске argocd-server происходит тайм-аут при попытке подключения к argocd-redis на 10.245.192.x:6379.
Я пробовал следующие подходы без успеха:
kube-proxy
Calico eBPF
Cilium kube-proxy-replacement
Трафик serviceSubnet по-прежнему не зашифрован и не может обойти ограничения межсетевого экрана.
Существует ли способ обойти это ограничение межсетевого экрана для serviceSubnet или есть ли инструмент, который мог бы помочь в достижении этой цели?
Ответ или решение
Для обхода ограничений фаервола для serviceSubnet в Kubernetes, в условиях строго контролируемой сетевой среды, можно рассмотреть несколько методов, исходя из имеющихся данных. На данный момент, ваша проблема заключается в невозможности обеспечить зашифрованную связь внутри serviceSubnet. Несмотря на успешное использование Calico и WireGuard для podSubnet, serviceSubnet остается уязвимой.
Анализ проблемы
-
Окружение:
- Используются только внешние IP-адреса.
- Жесткие политики фаервола, которые разрешают только TCP/UDP.
- Запрещено использование IP Protocol 4 и возможность запроса входящего доступа к определенным диапазонам IP не предоставляется.
-
Текущее решение:
- Зашифрованная связь через Calico + WireGuard и Cilium + WireGuard для podSubnet.
- Проблема с незашифрованной связью для serviceSubnet.
Возможные решения
1. Виртуальные сетевые устройства (VPN)
Создайте VPN-туннель для шифрования всего трафика, проходящего через serviceSubnet. Рассмотрите использование OpenVPN или IPsec, которые могут обойти существующие ограничения, создав зашифрованный канал поверх TCP/UDP.
2. Использование mesh-сетей
Сетевые решения, такие как Istio или Linkerd, могут помочь в шифровании внутреннего трафика. Эти решения предусматривают введение sidecar-контейнеров, которые управляют шифрованием и маршрутизацией трафика между службами.
3. Зашифрованные туннели на уровне приложения
Если VPN и mesh-сети недоступны, можно реализовать шифрование на уровне конкретных приложений. Это потребует изменения конфигурации приложений, таких как ArgoCD, для использования TLS-соединений внутри кластера.
4. Замена kube-proxy
Поскольку уже предприняты попытки с заменой kube-proxy, можно дополнительно исследовать возможности использования других сетевых плагинов или настройки существующих для поддержки шифрования serviceSubnet, возможно, через специальные настройки WireGuard, чтобы включить машинное шифрование на уровне самого пакета.
Заключение
Соблюдайте осторожность при внедрении подобных решений, так как они могут повысить сложность и повлиять на производительность. Также необходимо учитывать поддержание согласования с политиками безопасности вашей организации. В описанной ситуации VPN или mesh-сети представляют собой наименее инвазивное решение для обеспечения безопасности и обхода фаервола.