Введение в сетевые политики для деплойментов в Kubernetes

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

1. Что такое сетевые политики?

Kubernetes предоставляет абстракции для управления сетевыми взаимодействиями между подами с помощью сетевых политик (Network Policies). Сетевые политики позволяют вам контролировать, какой трафик может поступать в под и исходить из него, исходя из IP-адресов, меток подов и пространств имен.

Когда вы деплоите приложение в кластер Kubernetes, каждый под по умолчанию может обмениваться данными с любым другим подом в пределах одного кластера. Это открытая модель сетевого взаимодействия, которая может привести к проблемам с безопасностью. Сетевые политики позволяют ограничить доступ к вашим подам только тем узлам и подам, которые действительно должны иметь такой доступ.

2. Почему сетевые политики важны?

Сетевые политики особенно полезны в производственных средах, где кластер Kubernetes может содержать множество приложений и сервисов с различными требованиями к безопасности. Основные преимущества использования сетевых политик включают:

• Контроль сетевого трафика: Позволяет разрешать или блокировать сетевые взаимодействия на основе конкретных правил.
• Повышение безопасности: Ограничивая трафик между подами, можно предотвратить нежелательные или вредоносные соединения.
• Микросегментация: Обеспечивает изоляцию различных частей приложения на уровне сети, создавая «подзоны» безопасности.

Сетевые политики обеспечивают дополнительный уровень безопасности поверх других механизмов Kubernetes, таких как контроль доступа на основе ролей (RBAC) и политики безопасности подов.

3. Основы сетевых политик

Сетевые политики применяются к подам и управляют входящим и исходящим трафиком на уровне IP. Они основаны на следующих ключевых компонентах:

1. Под (Pod): Основная единица в Kubernetes, содержащая ваше приложение. Каждая сеть политика определяет, какие поды она должна защищать.
2. Namespace: Пространство имен, в котором находятся поды. Политики могут быть определены для одного пространства имен или нескольких.
3. Selectors (Селекторы): Для определения, какие поды и пространства имен затронуты политикой. Это могут быть метки подов (label selector) и селекторы пространств имен.
4. Ingress и Egress (Входящий и исходящий трафик): Политики могут управлять как входящим, так и исходящим трафиком. Входящие политики определяют, откуда может поступать трафик, а исходящие — куда трафик может отправляться.

Пример базовой сетевой политики

Пример сетевой политики, которая разрешает только входящие соединения с подов, имеющих метку app=frontend, выглядит следующим образом:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: allow-ingress-frontend

  namespace: default

spec:

  podSelector:

    matchLabels:

      app: backend

  policyTypes:

  - Ingress

  ingress:

  - from:

    - podSelector:

        matchLabels:

          app: frontend

В этом примере политика разрешает трафик только от подов с меткой app=frontend на поды с меткой app=backend.

4. Виды сетевых политик

Политика входящего трафика (Ingress)

Политики входящего трафика позволяют вам контролировать, какой трафик может достигать подов внутри кластера. Без политики входа (Ingress), любой под в кластере Kubernetes может послать трафик на другие поды. Пример:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: allow-specified-namespace-ingress

  namespace: my-namespace

spec:

  podSelector:

    matchLabels:

      role: db

  policyTypes:

  - Ingress

  ingress:

  - from:

    - namespaceSelector:

        matchLabels:

          purpose: monitoring

Здесь политика разрешает входящий трафик только от подов, находящихся в пространстве имен с меткой purpose=monitoring.

Политика исходящего трафика (Egress)

Исходящие сетевые политики ограничивают трафик, который выходит из подов. В случае, если политика исходящего трафика не задана, поды могут свободно посылать трафик на любые другие поды или IP-адреса за пределами кластера. Пример исходящей политики:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: deny-all-egress

  namespace: default

spec:

  podSelector:

    matchLabels:

      app: backend

  policyTypes:

  - Egress

  egress:

  - to:

    - podSelector:

        matchLabels:

          app: database

Этот пример политики ограничивает трафик от подов с меткой app=backend только на поды с меткой app=database.

Политика "deny-all"

Политики могут быть настроены для полного запрета входящего или исходящего трафика. Такие политики полезны для создания полностью закрытой сетевой среды, где доступ к подам предоставляется только по четко определенным правилам. Например:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

  name: deny-all-ingress

  namespace: my-namespace

spec:

  podSelector: {}

  policyTypes:

  - Ingress

Эта политика запрещает весь входящий трафик на все поды в пространстве имен my-namespace.

5. Как создаются и применяются сетевые политики

5.1 Создание сетевых политик

Сетевые политики в Kubernetes создаются как объект NetworkPolicy, который описывается в YAML-файле. Вы можете создать объект сетевой политики, как и любой другой объект Kubernetes, используя команду kubectl apply:

kubectl apply -f policy.yaml

Где policy.yaml — это ваш файл с определением сетевой политики.

5.2 Применение политики

Когда вы применяете сетевую политику, она начинает действовать для подов, соответствующих критериям podSelector. Например, если политика определена для подов с меткой app=backend, то все поды с этой меткой будут защищены сетевой политикой.

Если в пространстве имен нет сетевой политики, то весь трафик по умолчанию разрешён. Однако, как только вы создаете сетевую политику, только тот трафик, который явно разрешен этой политикой, будет разрешен.

5.3 Проверка работы сетевой политики

После применения сетевой политики важно убедиться, что она работает так, как ожидалось. Вы можете использовать команды kubectl для получения информации о политике:

kubectl get networkpolicy -n <namespace>

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

6. Лучшие практики использования сетевых политик

Для эффективного использования сетевых политик в Kubernetes рекомендуется следовать ряду лучших практик:

• Принцип минимальных привилегий: Ограничивайте трафик между подами до минимально необходимого уровня. Не открывайте доступ ко всем подам по умолчанию.
• Микросегментация: Разделяйте поды на небольшие сегменты и применяйте различные сетевые политики к каждому сегменту, чтобы повысить безопасность.
• Изоляция пространства имен: Рассматривайте возможность использования сетевых политик для создания барьеров между различными пространствами имен в кластере.
• Тестирование и мониторинг: Регулярно проверяйте работоспособность сетевых политик и используйте инструменты мониторинга для отслеживания сетевого трафика в кластере.
• Автоматизация: Рассмотрите возможность автоматизации создания и управления сетевыми политиками с помощью таких инструментов, как GitOps и CI/CD.

7. Заключение

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