Мы не договорили! 😁 Недавно делали подборку про Network Policy в Kubernetes, сегодня хочется сделать тематический день и рассказать про управление трафиком в Kubernetes-кластере с Calico.
Поехали! 💻
Одно из ключевых и очевидных преимуществ Calico перед другими плагинами — это значительное расширение функционала для настройки сетевых политик — возможность в качестве источников и целей при создании правил задавать диапазоны портов и IP-адресов, протоколы, атрибуты HTTP-запросов, и даже возможность задавать логирование определенного трафика.
Помимо этого Calico добавляет свою политику GlobalNetworkPolicy. Она позволяет применять набор правил доступа по селектору не только для pod’ов, но и для групп хостов/контейнеров/pod’ов, и контролировать применение мер безопасности для различных цепочек путей трафика с помощью таких параметров, как preDNAT, doNotTrack и applyOnForward.
Задачу по обеспечению базовых принципов безопасности мы условно разделим на две:
1) на подзадачу по настройке взаимодействия между pod’ами
2) на подзадачу по настройке доступа к узлу в целом
Решить первую подзадачу можно при помощи такой сущности Kubernetes как NetworkPolicies и при этом можно расширить функционал данной сущности, если использовать её с api, предоставляемого Calico. Для решения второй подзадачи мы будем использовать сущность GlobalNetworkPolicy. По ходу дела так же будем анализировать детали и начнем с Zero Trust Networking.
Zero Trust Networking
Первое, что стоит учесть при написании сетевых политик, это то, что и Kubernetes, и Calico считают наилучшим подход Zero Trust Networking, то есть по умолчанию запросы из используемой сети всегда считаются враждебными.
Согласно данной концепции существуют следующие требования к контролю доступа:
* Правила применяются ко всем сетевым подключениям (не только к тем, которые пересекают границы защищаемой зоны).
* Идентификация удаленного endpoint всегда основана на нескольких критериях, включая надежные криптографические доказательства идентичности. В частности, идентификаторы сетевого уровня, такие как IP-адрес и порт, сами по себе недостаточны, поскольку могут быть подделаны враждебной сетью.
* Все ожидаемые и разрешенные сетевые подключения явно указаны в белом списке. Любое соединение, явно не занесенное в белый список, отклоняется.
* Трафик от скомпрометированных workload (pod/VM/container) не должен иметь возможности обойти применение сетевых политик.
Во многих Zero Trust Networks также реализуется шифрование всего сетевого трафика. Это не является обязательным требованием (если речь идет не о передаче приватных данных), но для соответствия критериям Zero Trust Networks шифрование должно использоваться для каждого сетевого соединения.
Эти принципы влияют, к примеру, на следующее: если есть какая-либо сущность, имеющая метку, то по умолчанию весь трафик для неё разрешён. Но если будет создана хоть одна Policy, в которой будет фигурировать метка конкретной сущности, то для этой сущности будет запрещён весь трафик, кроме того, который был явно разрешён в только что созданной или уже имеющихся политиках.
Аналогично с HostEndpoint, как только он будет создан, весь трафик к хосту будет запрещен, кроме определенного перечня портов, который останется открытым. Причем, даже если вы создадите политики, которые явно запрещают доступ к этим портам, они останутся открытыми.
Для того, чтобы запретить доступ к этим портам нужно будет изменить конфигурацию Felix. Felix — это компонент Calico, демон, запущенный на всех машинах, которые обслуживает Calico.
*️⃣1/6: продолжение следует :)
#лонгрид
Post #436
2.05K
- 🔥 16
- 👍 4