Облачная платформаAdvanced

Настройка Network Policies для ограничения доступа к Pod

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Network policies разрабатываются Kubernetes для ограничения доступа к pod. Как межсетевой экран на уровне приложений, network policies повышают безопасность сети. Возможности, поддерживаемые network policies, зависят от возможностей сетевых дополнений кластера.

По умолчанию, если в namespace нет ни одной политики, pods в этом namespace принимают трафик из любого источника и отправляют трафик в любой пункт назначения.

Для network policies доступны следующие селекторы:

  • namespaceSelector: выбирает определённые namespaces, для которых все pods должны быть разрешены в качестве источников ingress или пунктов назначения egress.
  • podSelector: выбирает определённые pods в том же namespace, что и network policy, которые должны быть разрешены в качестве источников ingress или пунктов назначения egress.
  • ipBlock: выбирает определённые CIDR‑блоки, которые разрешаются в качестве источников ingress или пунктов назначения egress.

Взаимосвязь между Network Policies и типами кластеров

Тип кластера

CCE Standard Cluster

CCE Standard Cluster

CCE Turbo Cluster

Сетевая модель

Туннель

VPC

Cloud Native Network 2.0

Политики сети

Включено по умолчанию

Отключено по умолчанию (Чтобы использовать политики сети, включите DataPlane V2 при создании кластера.)

Отключено по умолчанию (Чтобы использовать политики сети, включите DataPlane V2 при создании кластера.)

Реализация плоскости данных

OpenvSwitch

eBPF

eBPF

Версия кластера для правил входящего трафика

Все версии

v1.27.16-r30, v1.28.15-r20, v1.29.13-r0, v1.30.10-r0, v1.31.6-r0, или более поздние

v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0, или более поздние

Версия кластера для правил исходящего трафика

v1.23 и более поздние

Селектор для правил входящего трафика

namespaceSelector

podSelector

namespaceSelector

podSelector

ipBlock

namespaceSelector

podSelector

ipBlock

Селектор для правил исходящего трафика

namespaceSelector

podSelector

ipBlock

Поддерживаемые ОС

EulerOS

CentOS

HCE OS 2.0

HCE OS 2.0 поддерживается.

Кластеры v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, v1.34.1-r0 и более поздние версии поддерживают Ubuntu 22.04.

HCE OS 2.0 поддерживается.

Кластеры v1.28.15-r70, v1.29.15-r30, v1.30.14-r30, v1.31.10-r30, v1.32.6-r30, v1.33.5-r20, v1.34.1-r0 и более поздние версии поддерживают Ubuntu 22.04.

Политики сети IPv6

Не поддерживается

Не поддерживается

Поддерживается

Защищённые контейнеры

Не поддерживается

Не поддерживается

Не поддерживается

Область IPBlock

Не ограничено

Подсети в пределах блока pod CIDR, блока Service CIDR и IP-адресов узлов

Подсети в пределах блока pod CIDR, блока Service CIDR и IP-адресов узлов

Ограничение доступа к ClusterIP через метки рабочих нагрузок

Не поддерживается

Поддерживается

Поддерживается

Ограничение внутреннего блока CIDR облачного сервера 100.125.0.0/16

Поддерживается

Поддерживается

Не поддерживается

SCTP

Не поддерживается

Поддерживается

Не поддерживается

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

Поддерживается

Поддерживается

Поддерживается

Настройка EndPort в network policies

Не поддерживается

Поддерживается

Не поддерживается

Note
  • DataPlane V2 кластеров CCE Turbo поставляется с ограничениями. Чтобы использовать эту функцию, отправьте запрос в службу поддержки CCE.
  • Защищённые контейнеры (например, Kata в качестве container runtime) не поддерживаются network policies.
  • Если вы обновляете стандартный кластер CCE с туннельной сетью до версии, поддерживающей правила egress в режиме in-place, правила не будут работать, поскольку ОС узла не обновлена. В этом случае выполните сброс узла.
  • Когда сетевая политика включена для кластера с туннельной сетью, исходный IP-адрес pod'а встраивается в необязательное поле пакетов, отправляемых им в любой блок Service CIDR. Это позволяет настраивать правила сетевой политики на целевом pod'е с учётом исходного IP-адреса pod'а.

Использование правил Ingress через YAML

  • Сценарий 1: Настройте сетевую политику, чтобы разрешить доступ к целевому pod'у только pod'ам с указанными метками.

    Рисунок 1 podSelector


    Pod с меткой role=db разрешает доступ к своему порту 6379 только от pod‑ов с меткой role=frontend. Чтобы выполнить это, выполните следующие действия:

    1. Создайте файл access-ingress1.yaml.
      vim access-ingress1.yaml

      Содержимое файла:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: access-ingress1
      namespace: default
      spec:
      podSelector: # The rule applies only to pods labeled with role=db .
      matchLabels:
      role: db
      ingress: # This is an ingress rule.
      - from:
      - podSelector: # Allow access only from pods labeled with role=frontend .
      matchLabels:
      role: frontend
      ports: # Only TCP can be used to access port 6379.
      - protocol: TCP
      port: 6379
    2. Выполните следующую команду для создания сетевой политики, определённой в файле access-ingress1.yaml:
      kubectl apply -f access-ingress1.yaml

      Ожидаемый вывод:

      networkpolicy.networking.k8s.io/access-ingress1 created
  • Сценарий 2: Настройте сетевую политику, позволяющую только pod‑ам в определённом пространстве имён получать доступ к целевому pod‑у.

    Figure 2 namespaceSelector


    Pod с меткой role=db разрешает доступ к своему порту 6379 только от pod‑ов в пространстве имён с меткой project=myproject. Чтобы выполнить это, выполните следующие действия:

    1. Создайте файл access-ingress2.yaml.
      vim access-ingress2.yaml

      Содержимое файла:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: access-ingress2
      spec:
      podSelector: # The rule applies only to pods labeled with role=db .
      matchLabels:
      role: db
      ingress: # This is an ingress rule.
      - from:
      - namespaceSelector: # Allow access only from pods in namespaces labeled with project=myproject .
      matchLabels:
      project: myproject
      ports: # Only TCP can be used to access port 6379.
      - protocol: TCP
      port: 6379
    2. Выполните следующую команду для создания сетевой политики, определённой в файле access-ingress2.yaml:
      kubectl apply -f access-ingress2.yaml

      Ожидаемый вывод:

      networkpolicy.networking.k8s.io/access-ingress2 created
  • Сценарий 3: Настройте сетевую политику, позволяющую только pod‑ам с определёнными метками в определённом пространстве имён получать доступ к целевому pod‑у.

    Figure 3 Используя одновременно podSelector и namespaceSelector


    Pod с меткой role=db разрешает доступ к своему порту 6379 только от pod‑ов с меткой role=frontend в пространстве имён с меткой project=myproject. Чтобы выполнить это, выполните следующие действия:

    1. Создайте файл access-ingress3.yaml.
      vim access-ingress3.yaml

      Содержимое файла:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: access-ingress3
      spec:
      podSelector: # The rule applies only to pods labeled with role=db .
      matchLabels:
      role: db
      ingress: # This is an ingress rule.
      - from:
      - namespaceSelector: # Allow access only from pods in namespaces labeled with project=myproject .
      matchLabels:
      project: myproject
      podSelector: # Allow access only from pods labeled with role=frontend .
      matchLabels:
      role: frontend
      ports: # Only TCP can be used to access port 6379.
      - protocol: TCP
      port: 6379
    2. Выполните следующую команду для создания сетевой политики, определённой в файле access-ingress3.yaml:
      kubectl apply -f access-ingress3.yaml

      Ожидаемый вывод:

      networkpolicy.networking.k8s.io/access-ingress3 created

Использование правил egress через YAML

Note

Кластеры v1.23 и более поздних версий, использующие туннельную сеть, поддерживают правила egress. Операционная система узла может быть только CentOS 7.x или HCE OS 2.0.

Правила egress доступны только в кластерах CCE Turbo или других кластерах CCE, использующих сети VPC. Версия кластера должна быть v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0 или более новой, и должен быть включён DataPlane V2. Кроме того, узлы в этих кластерах должны работать под управлением HCE OS 2.0.

  • Сценарий 1: При управлении предустановленной сетевой политикой pod‑ы могут обращаться только к определённым адресам.

    Рисунок 4 ipBlock


    Pod‑ы с меткой role=db допускают доступ только к 172.16.0.0/16, исключая 172.16.0.40/32. Чтобы достичь этого, выполните следующие действия:

    1. Создайте файл access-egress1.yaml.
      vim access-egress1.yaml

      Содержимое файла:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: access-egress1
      namespace: default
      spec:
      policyTypes: # This policy type must be specified for egress rules.
      - Egress
      podSelector: # The rule applies only to pods labeled with role=db .
      matchLabels:
      role: db
      egress: # This is an egress rule.
      - to:
      - ipBlock:
      cidr: 172.16.0.0/16 # Allows access to this CIDR block in the outbound direction.
      except:
      - 172.16.0.40/32 # Blocks access to this CIDR block, which is in the range specified by the cidr parameter.
    2. Выполните следующую команду для создания сетевой политики, определённой в файле access-egress1.yaml:
      kubectl apply -f access-egress1.yaml

      Ожидаемый вывод:

      networkpolicy.networking.k8s.io/access-egress1 created
  • Сценарий 2: При управлении предустановленной сетевой политикой pod может быть доступен только pod‑ам с определёнными метками, при этом сам этот pod может обращаться только к определённым pod‑ам.

    Рисунок 5 Использование как ingress, так и egress


    Под, помеченный role=db, разрешает доступ к своему порту 6379 только от подов, помеченных role=frontend, и этот под может обращаться только к подам, помеченным role=web. Вы можете использовать то же правило для настройки как ingress, так и egress в сетевой политике. Чтобы выполнить это, выполните следующие действия:

    1. Создайте файл access-egress2.yaml.
      vim access-egress2.yaml

      Содержимое файла:

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: access-egress2
      namespace: default
      spec:
      policyTypes:
      - Ingress
      - Egress
      podSelector: # The rule applies only to pods labeled with role=db .
      matchLabels:
      role: db
      ingress: # This is an ingress rule.
      - from:
      - podSelector: # Allow access only from pods labeled with role=frontend .
      matchLabels:
      role: frontend
      ports: # Only TCP can be used to access port 6379.
      - protocol: TCP
      port: 6379
      egress: # This is an egress rule.
      - to:
      - podSelector: # The rule takes effect for pods with the role=web label.
      matchLabels:
      role: web
    2. Выполните следующую команду для создания сетевой политики, определённой в файле access-egress2.yaml:
      kubectl apply -f access-egress2.yaml

      Ожидаемый вывод:

      networkpolicy.networking.k8s.io/access-egress2 created

Создание сетевой политики в консоли

  1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
  2. Выберите Policies в панели навигации, нажмите вкладку Network Policies и нажмите Create Network Policy в правом верхнем углу.

    • Policy Name: Укажите имя сетевой политики.
    • Namespace: Выберите пространство имён, в котором применяется сетевая политика.
    • Selector: Введите метку, выберите под для ассоциации и нажмите Add. Вы также можете нажать Reference Workload Label, чтобы использовать метку существующей рабочей нагрузки.
    • Inbound Rule: Нажмите , чтобы добавить входящее правило. Подробную информацию о параметрах см. в Table 1.

      Table 1 Добавление входящего правила

      Parameter

      Описание

      Protocol & Port

      Выберите тип протокола и порт. В настоящее время поддерживаются TCP и UDP.

      Source CIDR Block

      Для кластеров v1.27.16-r10, v1.28.15-r0, v1.29.10-r0, v1.30.6-r0 или более поздних версий с включённым DataPlane V2 вы можете настроить блок исходного CIDR.

      Указанный блок исходного CIDR позволяет трафик из блока назначения CIDR (можно указать несколько блоков CIDR‑исключений). Разделяйте блоки назначения и исключения вертикальной чертой (|). Если указано несколько блоков CIDR‑исключений, разделяйте их запятыми (,). Например, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 указывает, что 172.17.0.0/16 доступен, а 172.17.1.0/24 и 172.17.2.0/24 недоступны.

      Source Namespace

      Выберите пространство имён, объекты которого могут быть доступны. Если этот параметр не указан, объект принадлежит тому же пространству имён, что и текущая политика.

      Source Pod Label

      Разрешить доступ к pod‑ам с этой меткой. Если этот параметр не указан, доступны все pod‑ы в пространстве имён.

    • Outbound Rule: нажмите , чтобы добавить outbound rule. Для получения подробной информации о параметрах см. Table 2.

      Table 2 Добавление outbound rule

      Параметр

      Описание

      Protocol & Port

      Выберите тип протокола и порт. В настоящее время поддерживаются TCP и UDP. Если этот параметр не указан, тип протокола не ограничен.

      Destination CIDR Block

      Разрешить маршрутизацию запросов к указанному CIDR‑блоку (и не к CIDR‑блокам‑исключения). Разделяйте целевой и исключающие CIDR‑блоки вертикальной чертой (|). Если имеется несколько CIDR‑блоков‑исключений, разделяйте их запятыми (,). Например, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 указывает, что 172.17.0.0/16 доступен, а 172.17.1.0/24 и 172.17.2.0/24 недоступны.

      Destination Namespace

      Выберите namespace, объекты которого могут быть доступны. Если этот параметр не указан, объект принадлежит тому же namespace, что и текущая политика.

      Destination Pod Label

      Разрешить доступ к pod‑ам с этой label. Если этот параметр не указан, доступны все pod‑ы в namespace.

  3. нажмите OK.