Блог

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

Теперь идея состоит в том, чтобы по умолчанию разрешить трафик В пространствах имен с порядком выше запрета по умолчанию. Однако мне не удалось найти здесь масштабируемый подход. Похоже, что нам нужно явно создать NetworkPolicy для каждого нового пространства имен, которое выглядит в основном одинаково.

Я ищу что-то вроде этого: вы определяете правило один раз, и оно применяется ко всем ресурсам в пространстве имен с allow-all-in-ns меткой.

 apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-self-policy
spec:
  namespaceSelector: 'has(allow-all-in-ns)'
  ingress:
  - action: Allow
    source:
      namespaceSelector: has(allow-all-in-ns) amp;amp; self
  egress:
  - action: Allow
    source:
      namespaceSelector: has(allow-all-in-ns) amp;amp; self
 

Я не хочу никакой связи между пространствами имен с меткой allow-all-in-ns , но я хочу связи внутри каждого пространства имен с этой меткой. Возможно ли это в настоящее время с набором функций calico?

Хотя Namespaces вы можете изолировать объекты в определенные группы, они не обеспечивают никакой изоляции. Возможно наличие межименного трафика (подробнее см. Здесь), что означает, что если контейнер просто использует, он будет разрешен службе, которая является локальной для пространства имен. Это полезно для использования одной и той же конфигурации в нескольких пространствах имен, таких как Development, Staging и Production. Если вы хотите охватить все пространства имен, вам необходимо использовать полное доменное имя (FQDN).

Чтобы решить эту проблему, у нас есть NetworkPolicy , который после применения с соответствующим селектором может быть использован для изоляции трафика между объектами кластера. Подробнее об этом вы можете узнать здесь.

К сожалению, нет никакого способа получить то, что вы описали, и, если я правильно понимаю политику, которую вы хотите применить, вам будет отказано в доступе к вашим kube-system модулям, особенно core-dns к тем, которые необходимы для кластерной сети.

Поскольку GlobalNetworkPolicy применяется глобально, вы можете использовать это по умолчанию -запретить все, кроме тех, с kube-system которыми, а затем использовать NetworkPolicies для каждого модуля и ограничить их egress , и ingress с некоторой маркировкой оставить место только для разрешенного трафика.

Правила политики Calico можно заказать для принудительного применения либо до, либо после политик K8s и включают в себя множество действий, таких как запретить и войти. Это позволяет команде security / cluster ops определять базовые высокоуровневые правила общего назначения moge, а команде разработчиков / служб / пользователей кластера определять свои собственные детализированные правила для приложений и служб, за которые они отвечают. Проверьте этот документ для получения дополнительной информации о порядке оценки.

Поскольку правила политики Calico могут быть предписаны для принудительного применения либо до, либо после сетевых политик Kubernetes и могут включать такие действия, как запрещение и регистрация, это позволяет команде security / cluster ops определять базовые правила более общего назначения более высокого уровня, в то же время предоставляя разработчикам / сервисным группам возможность определять свои собственные-зернистые ограничения на приложения и службы, за которые они отвечают.

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

Один из наиболее распространенных подходов — иметь небольшое количество глобальных политик, которые применяются ко всем модулям, а затем одну политику, специфичную для pod, которая определяет все правила входа и выхода, характерные для этого pod.

Вы можете прочитать больше о лучших практиках и default-deny на сайте calico.

Подводя итог, после просмотра документации calico невозможно создать одно единственное правило, которое будет делать то, чего вы хотите достичь. Другой способ добиться этого — возможно, использовать helm и его диаграммы для автоматизации процесса создания дополнительных сетевых политик.