Как я могу гарантировать, что TCP-трафик проксируется сопроводительным файлом Envoy при использовании Istio в Kubernetes?

Istio в Kubernetes внедряет сопроводительный файл Envoy для работы вместе с модулями и реализует сервисную сетку, однако сам Istio не могут гарантировать, что трафик не будет обходить этот прокси; в этом случае политика безопасности Istio больше не применяется.

Поэтому я пытаюсь понять все способы, которыми может произойти этот обход (при условии, что сам Envoy не был скомпрометирован), и найти способы предотвратить их, чтобы трафик TCP, исходящий из сетевого пространства имен Pod, гарантированно проходил через Envoy (или по крайней мере, гораздо более вероятно):

  1. Поскольку (на момент написания) Envoy не поддерживает UDP (это почти здесь) , Трафик UDP не будет проксироваться, поэтому используйте NetworkPolicy, чтобы убедитесь, что только TCP-трафик разрешен к / из Pod (например, чтобы избежать туннелирования TCP-трафика через VPN через UDP)
  2. Откажитесь от возможности NET_ADMIN, чтобы блок не переконфигурировал правила IPTables в своем сетевом пространстве имен, которые захватывают трафик.
  3. Отбросьте возможность NET_RAW для предотвращения открытия модулем сырых сокетов и обхода точек подключения netfilter, которые использует IPTables.

Единственный другой вектор атаки, о котором я знаю, - это уязвимость ядра - есть ли другие? Может быть, есть другие протоколы L3 / 4, которые IPTables не распознает или игнорирует?

Я понимаю, что eBPF и Cilium могут использоваться для принудительного перехвата в сокете уровень, но меня интересует случай использования ванильного Istio на Kubernetes.

РЕДАКТИРОВАТЬ: я также предполагаю, что рабочая нагрузка не имеет доступа к серверу Kubernetes API


kubernetes kubernetes-networkpolicy istio envoyproxy network-security
person dippynark    schedule 20.11.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Envoy не предназначен для использования в качестве межсетевого экрана. Сетевые службы, которые полагаются на него, такие как Istio или Cilium, считают это ошибкой только в том случае, если вы можете обойти политики на принимающей стороне.

Например, любой pod может тривиально обойти любые политики Istio или Cilium, завершив свой собственный Envoy с помощью curl localhost:15000/quitquitquit и запустив собственный прокси-сервер на порту 15001, который разрешает все до перезапуска Envoy.

Вы можете залатать эту конкретную дыру, но поскольку противодействие таким атакам не является целью разработки для сервисных сеток, вероятно, есть десятки других способов сделать то же самое. Новые способы обхода этих политик также могут быть добавлены в последующих выпусках.

Если вы хотите, чтобы ваши политики безопасности применялись на стороне, инициирующей соединение, а не только на принимающей стороне, рассмотрите возможность использования реализации сетевой политики, для которой она является целью разработки, например Calico.

person Shnatsel    schedule 21.11.2019
comment
AFAIK вы можете использовать Cilium для реализации сетевых политик Kubernetes, которые могут заносить в белый список трафик, разрешенный для определенных подов, чтобы ограничить его определенными портами, независимо от того, что делает сервисная сетка. (cilium.io/blog/2018/09/19/kubernetes- сетевые политики) - person Rory McCune; 21.11.2019
comment
Возможно, что пример, который вы связали, работает, потому что политики применяются на принимающей стороне соединения. Я не уверен на 100% насчет Cilium, но с Istio вы определенно не можете полагаться на то, что Envoy вашего пода действительно что-либо применяет. (Источник: я говорил об этом с разработчиком Istio). - person Shnatsel; 21.11.2019
comment
Это здорово curl -X POST 127.0.0.1:15000/quitquitquit отключает у меня прокси. Я считаю, что этот момент / возможность следует прояснить в документации (по крайней мере, я не сталкивался с этим раньше). - person dippynark; 21.11.2019

arrow_upward
-1
arrow_downward

Envoy относительно просто обойти, а Cilium использует envoy точно так же, как Istio. Так что он не сможет предотвратить обход апстрима посланника.

И Istio, и Cilium есть сайты, на которых перечислены CVE об уязвимостях безопасности.

Изнутри плоскости управления можно повлиять на правила инъекции sidecar или iptables с помощью аннотаций, поэтому, как только кто-то получит доступ к привилегиям администратора кластера, защиты не будет.

Вы можете использовать calico, чтобы заблокировать связь, так что единственным потоком трафика является трафик вы хотите течь.

Calico также предлагает бесшовную интеграцию с Istio для обеспечения соблюдения сетевой политики внутри сервисная сетка Istio.

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

Обновлять:

Чтобы прояснить ситуацию, я предложил ситцевую сетку для сетевой модели с нулевым доверием. Без него вы можете связываться с посланником из модуля приложения, поскольку они находятся в той же сети, что и интерфейс администратора. Таким образом, блокировка связи между модулем приложения и интерфейсом администратора является жизненно важным исправлением уязвимости.

Даже без прав администратора кластера вы можете воздействовать на envoy из модуля приложения с помощью команды curl.

person Piotr Malec    schedule 20.11.2019
comment
Я не думаю, что это все правильно или актуально 1) Плагин CNI Cilium действительно помогает предотвратить обход с использованием eBPF и sockmaps путем перехвата создания сокета TCP (см. Видео по ссылке) 2) CVE, на которые вы ссылаетесь, были исправлено 3) вы не можете повысить привилегии до администратора кластера, если у вас их еще нет, без какой-либо серьезной уязвимости k8s (и в любом случае у вас есть более серьезные проблемы в этом случае) - я говорю о нормальной рабочей нагрузке, у которой нет API доступ к серверу (должен был уточнить, но думал, что это ясно из перечисленных атак) 4) Calico - не единственная реализация сетевой политики - person dippynark; 20.11.2019