AWS network policy

А там разве встроенный CNI не поддерживает сетевые политики?

Вот здесь и вопрос. Как эти политики прописать. Может есть какая документация? Помогите, пожалуйста

Как всегда, официальная документация? Вот, например https://kubernetes.io/docs/concepts/services-networking/network-policies/

Мдеее. Да, походу там реально этого нет. У них там какой-то примитивный CNI. Даже в DigitalOcean Cillium по дефолту.

Кстати, можно, использовать Cillium. Я особо не шарю по нему, но все говорят, что пушка

https://docs.cilium.io/en/v1.9/gettingstarted/k8s-install-eks/

Проблема в том, что ничего устанавливать нельзя. Нужно использовать только то, что уже есть в EKS

Вроде есть что-то:

• https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html
• https://aws.amazon.com/blogs/containers/introducing-security-groups-for-pods/

Но там имеются ограничения (см. первую ссылку), в том числе, на поддерживаемые типы EC2-узлов кластера.

После того, как группу заассайнила на под - полностью пропал исходящий трафик. Не могу даже apt-get update сделать. Все настройки сделала по документации((

Ну, возникший эффект говорит о том, что security-группы все же как-то прикручиваются к Pod-ам ) Осталось выяснить, как это правильно сделать… ))

Я сам не юзал эту фичу, поэтому более детально ничего сказать не могу. У вас, кстати, какая версия Kubernetes используется? И какого типа EC2-узлы? CNI-плагин установлен? На старых версиях я раньше вообще CNI-плагин не использовал - только недавно установил, когда версию Kubernetes подтягивал.

EC2 -m5 VPC CNI - установлен Kubernetes - 1.25

Може есть какие то хитрости в настройке правил? Гдето попалась инфа, что надо указывать два правила. Для сети и для подов

По указанным выше ссылкам вроде приведены конкретные примеры подключения групп к подам - типа, делай раз, делай два… Можно эти примеры просто упростить подняв на одном поде пустой Nginx-сервер, а на другом - произвольном - установить curl зайдя в него через kubectl exec. Ну и попробовать пооткрывать-позакрывать 80-й порт Nginx-пода меняя конфигурацию соответствующей группы и проверяя доступ из второго пода curl-ом.

А вообще, для чего потребовалось разграничивать сетевой доступ между подами во внутренней сети кластера?

Не только внутри но и исходящие должны быть ограничены. Такое требование. Судя по всему, мне нужно отдельно прикрутить NAT gateway. Чтобы поды могли в инет ходить. Может поможете информацией, как это правильно сделать?

После привзки групп к подам, на них пропадает интернет. Нашла такую инфу - «Source NAT is disabled for outbound traffic from pods with assigned security groups so that outbound security group rules are applied. To access the internet, pods with assigned security groups must be launched on nodes that are deployed in a private subnet configured with a NAT gateway or instance. Pods with assigned security groups deployed to public subnets are not able to access the internet.»

Только не имею понимания, как можно реализовать. У меня 1 VPC с тремя подсетями

Не только внутри но и исходящие должны быть ограничены.

Ну, между собой-то поды должны общаться - или тоже нет? Слабо могу себе представить k8s-кластер, где поды полностью изолированы друг от друга в сетевом плане. Поэтому и задал вопрос на тему, какую конкретно проблему вы хотите решить? Для какого типа кластерного приложения потребовались такие ограничения?

Судя по всему, мне нужно отдельно прикрутить NAT gateway. Чтобы поды могли в инет ходить.

NAT gateway требуется, если вы создали кластер в private-подсетке VPC. В этом случае EC2-узлы кластера (не путать с подами) изолированы от Internet и не имеют public IP-адресов. Соответственно, сами по себе в инет ходить не могут - только через NAT-сервис. Этот механизм действует на уровне EC2-узлов и VPC.

Нужно сделать, чтобы поды в кластере общались между собой через разрешенные порты. Это можно прописать в inbound и outbound правилах. А, для некоторых, нужен выход в интернет для обращения к внешним сервисам. Сейчас меня больше интересует именно выход в интернет. Так как доступ к нему пропадает, после назначени групп безопасности

После привязки групп к подам, на них пропадает интернет…

Входящие (inbound) соединения из Интернет напрямую на поды попадать не могут - только через балансировщики. Поды прикручиваются к виртуальной подсети Kubernetes (не путать с VPC) и в принципе не имеют public IP-адресов.

Выход в Интернет подов (outbound) осуществляется при посредстве EC2-узлов. Если EC2-узлы крутятся в public-подсетке VPC, то исходящие соединения транслируются в Интернет непосредственно EC2-узлами. Приемная сторона видит эти соединения как соединения, исходящие от public IP-адресов EC2-узлов.
Если EC2-узлы крутятся в private-подсетке VPC, то они могут транслировать в Интернет исходящий траффик подов только при наличии NAT gateway в VPC.

Ну т.е. все как в обычном Docker-е …

… Только не имею понимания, как можно реализовать. У меня 1 VPC с тремя подсетями.

Inbound-траффик из Интернет (типа, входящие SSH-соединения) напрямую может попадать только на EC2-узлы, имеющие public IP-адреса, т.е. поключенные к public-подсетке VPC.

Чтобы полностью защититься от потенциального внешнего взлома EC2-узлов всякими «вражинами», узлы можно подключить к private-подсетке VPC - ну, т.е.создать Kubernetes-кластер с private-подсеткой. Но если при этом требуется выход наружу из подов, то придется подключать NAT gateway и платить за него денежку.

Вот как-то так…

Нужно сделать, чтобы поды в кластере общались между собой через разрешенные порты.

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

Теоретически, можно накладывать дополнительные ограничения на IP-шники клиентов - типа, разрешать доступ к портам пода только для конкретного диапазона IP-адресов. Вот здесь и можно прикрутить security groups указав соответствующие ограничения в inboud rules. Как-то ограничивать траффик в outbound rules такой группы не имеет смысла, да и не понятно зачем - там надо оставить полное разрешение.

В одной из security group я настроила разрешения исходящего трафика только на порт базы. Которая в том же VPC. Но трафик для пода вообще пропал

Вообще-то поду, как правило, нужно обращаться и к другим сервисам - к примеру, к внутреннему DNS-сервису. IP-щник той же базы данных может меняться со временем. Поэтому накладывать ограничения в outbound rules можно только в редких, специфичных случаях - и четко понимая, что вы делаете и к каким последствиям это может привести.

Так что, лучше не трогайте «outbound rules» без особой на то необходимости.

… если имеются требования супер-супер безопасности - типа, чтобы взломщик пода не мог как угодно «шариться» по внутренней сети кластера - ну тогда выясняйте все внешние системные порты, по которым поду реально требуется обращаться к другим подам-сервисам, и добавляйте их в «outbound rules».

Проблема ещё в том, что при Allow all также пропадал доступ куда либо за пределы пода( И непонятно, что с этим делать

Проще говоря, я сделала правило «Allow all traffic» для inbound и outbound соединений. Но, никуда подключится не смогла

ну, тут мне сложно что-то добавить со стороны. Но раз AWS-ники предоставили такой сервис и расписали его в документации, то проблема скорее всего где-то в других настройках.