Безопасность сетевого трафика между подами с помощью сетевых политик в Azure Kubernetes Service (AKS)

Установите движок политики сети и создайте политики сети Kubernetes для управления потоком трафика между pod в кластерах AKS.

Общие сведения о политике сети

По умолчанию все контейнеры pod в кластере AKS могут отправлять и получать трафик без ограничений. Для повышения безопасности вы можете определить правила, управляющие потоком трафика.

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

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

Параметры политики сети в AKS

Azure предоставляет три подсистемы сетевой политики для применения политик сети:

• Cilium (для кластеров AKS с помощью Azure CNI Powered by Cilium)
• Диспетчер сетевых политик Azure (NPM)
• Calico (решение с открытым исходным кодом для сетей и сетевой безопасности, разработанное Tigera)

Рекомендуется использовать Cilium. Cilium применяет политику сети к трафику с помощью фильтра пакетов Linux Berkeley (BPF), что более эффективно, чем IPTables.

Чтобы применять указанные политики, Azure NPM использует IPTables для Linux и ACL-политики службы Host Network Service (HNS) для Windows. Политики преобразовываются в наборы разрешенных и запрещенных пар IP-адресов. Затем эти пары запрограммированы как IPTable или HNS ACLPolicy правила фильтров.

Различия между подсистемами политики сети: Cilium, Azure NPM и Calico

Ограничения Диспетчера сетевых политик Azure (Linux)

Azure NPM для Linux имеет следующие ограничения:

• Масштабирование за пределы 250 узлов и 20 000 подов не поддерживается. Если вы пытаетесь увеличить масштаб за пределами этих ограничений, может возникнуть ошибка "Вне памяти" (OOM). Для повышения масштабируемости и поддержки IPv6 рекомендуется использовать или обновить azure CNI с помощью Cilium для подсистемы политики сети.
• IPv6 не поддерживается. В противном случае она полностью поддерживает спецификации политики сети в Linux.

Ограничения диспетчера сетевых политик Azure (Windows)

Azure NPM для Windows не поддерживает следующие функции спецификаций политики сети:

• Именованные порты.
• Протокол управления передачей потоков (SCTP).
• Исключающие метки или селекторы пространства имен. Например, все метки, кроме debug=true.
• except Блоки бесклассовой междоменной маршрутизации (CIDR) с исключениями.

Известные проблемы с диспетчером сетевых политик Azure

При редактировании или удалении "достаточно большой" сетевой политики могут возникать временные проблемы с подключением новых подключений к модулям pod или из модулей pod на затронутых узлах. Попадание в это состояние гонки никогда не влияет на активные соединения.

Если это условие гонки возникает для узла, pod Azure NPM на этом узле переходит в состояние, в котором он не может обновлять правила безопасности, что может привести к неожиданным подключениям для новых соединений к pod или из pod на затронутом узле. Чтобы устранить проблему, модуль pod Azure NPM автоматически перезапускается примерно через 15 секунд после ввода этого состояния. Хотя NPM Azure перезагружается на затронутом узле, он удаляет все правила безопасности, а затем повторно применяет правила безопасности для всех политик сети. Хотя все правила безопасности применяются повторно, существует вероятность временного, неожиданного подключения для новых подключений к модулям или от них на затронутом узле.

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

Службы подсистемы балансировки нагрузки и политики сети

Маршрутизация служб Kubernetes для входящих и исходящих служб часто включает перезапись исходных и целевых IP-адресов на обрабатываемом трафике, включая трафик, поступающий в кластер из LoadBalancer службы. Это поведение перезаписи означает, что политики сети могут неправильно обрабатывать трафик, полученный от внешней службы или отправляемого в нее. Дополнительные сведения см. в документации по политикам сети Kubernetes.

Чтобы ограничить количество источников, которые могут отправлять трафик в службу подсистемы балансировки нагрузки, используйте spec.loadBalancerSourceRanges для настройки блокировки трафика, которая применяется перед перезаписями. Дополнительные сведения см. в документации по подсистеме балансировки нагрузки AKS Standard.

Прежде чем начать

Необходимо установить и настроить Azure CLI версии 2.0.61 или более поздней. Найдите версию с помощью az --version команды. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

Вместо удостоверения, назначаемого системой, можно также использовать удостоверение, назначаемое пользователем. Дополнительные сведения см. в статье о том, как использовать управляемые удостоверения.

Создание кластера AKS с помощью Диспетчера сетевых политик Azure (Linux)

1. Задайте переменные среды для имени группы ресурсов, имени кластера и расположения. Замените значения по мере необходимости.

   export RESOURCE_GROUP=myResourceGroup
   export CLUSTER_NAME=myAKSCluster
   export LOCATION=eastus
   

2. Создайте кластер AKS с помощью az aks create и укажите azure для network-plugin и network-policy.

   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --node-count 1 \
       --network-plugin azure \
       --network-policy azure \
       --generate-ssh-keys
   

Создание кластера AKS с помощью Диспетчера сетевых политик Azure (Windows Server 2022 (предварительная версия))

Установка расширения Azure CLI aks-preview

1. aks-preview Установите расширение с помощью az extension add команды.

   az extension add --name aks-preview
   

2. Обновите до последней версии расширения с помощью az extension update команды.

   az extension update --name aks-preview
   

Регистрация флага компонента WindowsNetworkPolicyPreview

1. Зарегистрируйте флаг функции WindowsNetworkPolicyPreview с помощью команды az feature register.

   az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"
   

   Через несколько минут отобразится состояние Registered (Зарегистрировано).

2. Проверьте состояние регистрации с помощью az feature show команды.

   az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"
   

3. Когда состояние показывает зарегистрировано, обновите регистрацию Microsoft.ContainerService поставщика ресурса с помощью команды az provider register.

   az provider register --namespace Microsoft.ContainerService
   

Создание учетных данных администратора для контейнеров Windows Server

• Создайте имя пользователя для использования в качестве учетных данных администратора для контейнеров Windows Server в кластере. Следующая команда запрашивает имя пользователя. Присвойте ему значение WINDOWS_USERNAME.

  echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME
  

Создание кластера AKS

1. Задайте переменные среды для имени группы ресурсов, имени кластера и расположения. Замените значения по мере необходимости.

   export RESOURCE_GROUP=myResourceGroup
   export CLUSTER_NAME=myAKSCluster
   export LOCATION=eastus
   

2. Создайте кластер AKS с помощью az aks create и укажите azure для network-plugin и network-policy.

   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --node-count 1 \
       --windows-admin-username $WINDOWS_USERNAME \
       --network-plugin azure \
       --network-policy azure \
       --generate-ssh-keys
   

Создание кластера AKS с помощью Calico

Создайте кластер AKS с помощью az aks create команды и укажите --network-plugin azure и --network-policy calico. Указание --network-policy calico включает Calico как в пулах узлов Linux, так и в пулах узлов Windows.

Если вы планируете добавить в кластер пулы узлов Windows, включите параметры windows-admin-username и windows-admin-password, которые соответствуют требованиям к паролям Windows Server. Сведения о создании учетных данных администратора для контейнеров Windows Server в кластере см. в статье "Создание учетных данных администратора для контейнеров Windows Server".

Установка диспетчера политик сети Azure или Calico в существующем кластере

• Обновите существующий кластер с помощью команды az aks update, чтобы установить Azure NPM или Calico, указав azure или calico для параметра --network-policy. В следующем примере показано, как установить Azure NPM:

  az aks update
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --network-policy azure
  

Обновление существующего кластера с помощью Azure NPM или Calico до Cilium

Чтобы обновить существующий кластер до Azure CNI Powered by Cilium, см. статью Об обновлении существующего кластера до Azure CNI Powered by Cilium

Подключение к кластеру AKS

• Настройте kubectl, чтобы подключиться к вашему кластеру с помощью команды az aks get-credentials. Эта команда скачивает учетные данные и настраивает интерфейс командной строки Kubernetes для их использования.

  az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
  

Проверка настройки политики сети

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

1. Создайте пространство имен demo, чтобы запустить поды-образцы с помощью команды kubectl create namespace.

   kubectl create namespace demo
   

2. Создайте pod с именем server для запуска сервера на TCP-порту 80 с помощью команды kubectl run.

   kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"
   

3. Создайте модуль pod с именем client для запуска Bash с помощью kubectl run команды.

   kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash
   

   Note

   Если вы хотите запланировать клиент или сервер на определенном узле, добавьте следующий бит перед --command аргументом в команде создания kubectl run pod: --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

4. В отдельном окне получите IP-адрес pod server с помощью команды kubectl get pod.

   kubectl get pod --output=wide -n demo
   

   Выходные данные должны выглядеть примерно так:

   NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
   server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>
   

Проверка подключения с помощью политик сети

1. Создайте файл demo-policy.yaml и вставьте в него следующий манифест YAML:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: demo-policy
     namespace: demo
   spec:
     podSelector:
       matchLabels:
         app: server
     ingress:
     - from:
       - podSelector:
           matchLabels:
             app: client
       ports:
       - port: 80
         protocol: TCP
   

2. Примените манифест политики сети с помощью kubectl apply команды.

   kubectl apply –f demo-policy.yaml
   

3. В клиентской оболочке проверьте подключение к серверу с помощью следующей /agnhost команды:

   /agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp
   

   Подключение по трафику блокируется, так как сервер помечен меткой app=server, но клиент не помечен. Выходные данные должны выглядеть примерно так:

   TIMEOUT
   

4. Промаркируйте client и проверьте соединение с сервером, используя команду kubectl label.

   kubectl label pod client -n demo app=client
   

   Если подключение выполнено успешно, выходные данные отсутствуют.

Переход на самостоятельное управление Calico

AKS поддерживает только Calico для стандартных политик сети Kubernetes и не проверяет другие функции. Если вы хотите перейти на самостоятельно управляемый Calico, следуйте инструкциям Tigera, приведенным в статье "Миграция с управляемого Azure Calico на самостоятельно управляемый Calico". В документации Tigera упоминается, что для самостоятельно управляемого Calico вы настраиваете --network-policy none, как в разделе удаления.

Удаление диспетчера сетевых политик Azure или Calico

• Удалите диспетчер политик сети Azure или Calico из существующего кластера с помощью az aks update команды и укажите none для --network-policy параметра.

  az aks update
      --resource-group $RESOURCE_GROUP \
      --name $CLUSTER_NAME \
      --network-policy none
  

Очистка ресурсов

В этой статье вы создали пространство имен и два модуля pod и применили политику сети. Если эти ресурсы больше не нужны, их можно удалить.

• Удалите ресурсы с помощью kubectl delete команды.

  kubectl delete namespace demo
  

Связанный контент

• Основные понятия сети для приложений в службе Azure Kubernetes (AKS)
• Политики сети Kubernetes