Best practices for network connectivity and security in Azure Kubernetes Service (AKS) (Рекомендации по подключению сетей и обеспечению безопасности в службе Azure Kubernetes (AKS))

  • Статья

Создавая кластеры и управляя ими в службе Azure Kubernetes (AKS), вы обеспечиваете сетевое подключение для узлов и приложений. К этим сетевым ресурсам относятся диапазоны IP-адресов, подсистемы балансировки нагрузки и контроллеры входящего трафика.

В этой статье приведены рекомендации для операторов кластеров, связанные с подключениями и безопасностью сетей. Вы узнаете, как выполнять следующие задачи:

  • Сравнение сетевых режимов kubenet с сетевым интерфейсом контейнеров Azure (CNI) в AKS.
  • Планирование требуемой IP-адресации и возможности подключения.
  • Распределение трафика с помощью подсистем балансировки нагрузки, контроллеров входящего трафика и брандмауэра веб-приложений (WAF).
  • Защищенное подключение к узлам кластера.

выбор подходящей сетевой модели.

Рекомендации по рекомендациям

Используйте сеть Azure CNI в AKS для интеграции с существующими виртуальными или локальными сетями. Эта сетевая модель позволяет изолировать ресурсы и элементы управления в среде предприятия.

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

  • Сеть Azure CNI: развертывается в виртуальной сети и использует подключаемый модуль Azure CNI Kubernetes. Группы pod получают отдельные IP-адреса, которые можно направлять к другим службам сети или локальным ресурсам.
  • Сеть Kubenet: Azure управляет ресурсами виртуальной сети по мере развертывания кластера и использует подключаемый модуль kubenet Kubernetes.

Azure CNI и kubenet являются допустимыми вариантами для рабочих развертываний.

Сеть CNI

Azure CNI — это независимый от поставщиков протокол, который позволяет среде выполнения контейнера выполнять запросы к поставщику сети. Он назначает IP-адреса группам pod и узлам, а также предоставляет функции управления IP-адресами (IPAM) при подключении к существующим виртуальным сетям Azure. Каждый узел и ресурс pod получают IP-адрес в виртуальной сети Azure. Для обмена данными с другими ресурсами или службами не требуется дополнительная маршрутизация.

Схема, демонстрирующая два узла с мостами, подключающими каждый из них к одной виртуальной сети Azure

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

При использовании сети Azure CNI ресурс виртуальной сети размещается в отдельной группе ресурсов относительно кластера AKS. Делегируйте разрешения удостоверению кластера AKS для доступа к этим ресурсам и управления ими. Удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере разрешения Участник сетей в подсети виртуальной сети.

Если вы хотите определить пользовательскую роль вместо того, чтобы использовать встроенную роль участника сети, требуются следующие разрешения:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

По умолчанию AKS использует управляемое удостоверение для своего удостоверения кластера. Однако вместо этого можно использовать субъект-службу.

Так как каждый узел и узел pod получают собственный IP-адрес, спланируйте диапазоны адресов для подсетей AKS. Имейте в виду следующие критерии:

  • Подсеть должна быть достаточно большой, чтобы предоставить IP-адреса для каждого узла, модуля pod и развернутого сетевого ресурса.
    • При использовании сети kubenet и Azure CNI каждый запущенный узел имеет ограничения по умолчанию на количество модулей pod.
  • Старайтесь не использовать диапазоны IP-адресов, перекрывающие существующие сетевые ресурсы.
    • Необходимо разрешить подключение к локальным или пиринговым сетям в Azure.
  • Для обработки событий горизонтального масштабирования или обновления кластеров потребуются дополнительные IP-адреса, доступные в назначенной подсети.
    • Это дополнительное адресное пространство особенно важно при использовании контейнеров Windows Server, так эти пулы узлов нужно обновлять для установки последних исправлений системы безопасности. Подробности про узлы Windows Server см. в статье Обновление пула узлов в AKS.

Дополнительные сведения о планировании необходимых IP-адресов см. в статье о настройке сети Azure CNI в AKS.

При создании кластера с сетями Azure CNI вы указываете другие диапазоны адресов для кластера, такие как адрес моста Docker, IP-адреса службы DNS и диапазон адресов службы. Как правило, убедитесь, что эти диапазоны адресов не перекрываются друг с другом или любыми сетями, связанными с кластером, включая любые виртуальные сети, подсети, локальные и пиринговые сети.

Подробные сведения об ограничениях и размерах для этих диапазонов адресов см. в статье Настройка сети Azure CNI в AKS.

Сеть Kubenet

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

  • Так как узлы и модули хранятся в разных IP-подсетях, определяемая пользователем маршрутизация (UDR) и IP-передача перенаправляют трафик между модулями pod и узлами. Такая дополнительная маршрутизация может снизить производительность сети.
  • Подключения к существующим локальным сетям или пиринговые подключения к другим виртуальным сетям Azure могут быть сложными.

Так как вы не создаете виртуальную сеть и подсети отдельно от кластера AKS, Kubenet идеально подходит для следующих сценариев:

  • Небольших рабочих нагрузок разработки или тестирования.
  • Простых веб-сайтов с низким уровнем трафика.
  • Поднятия рабочих нагрузок и их сдвига в контейнеры.

Использование kubenet и Azure CNI допустимо для рабочих развертываний. Среды, требующие разделения элементов управления и управления, Azure CNI может использовать предпочтительный вариант. Кроме того, kubenet подходит только для сред Linux, где сохранение диапазона IP-адресов является приоритетом.

Вы также можете настроить собственные диапазоны IP-адресов и виртуальные сети для использования с kubenet. Как и сеть Azure CNI, эти диапазоны адресов не должны перекрываться друг с другом или любыми сетями, связанными с кластером (виртуальные сети, подсети, локальные и пиринговые сети).

Подробные сведения об ограничениях и размерах для этих диапазонов адресов см. в статье Использование сети kubenet с собственными диапазонами IP-адресов в AKS.

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

Рекомендации по рекомендациям

Чтобы распределить трафик HTTP или HTTPS между приложениями, используйте ресурсы и контроллеры входящего трафика. По сравнению с подсистемой балансировки нагрузки Azure контроллеры входящего трафика предоставляют дополнительные возможности, и управлять ими можно как собственными ресурсами Kubernetes.

В то время, как подсистема балансировки нагрузки Azure может распределять клиентский трафик между приложениями в кластере AKS, ее возможности по распознаванию этого трафика ограничены. Ресурс подсистемы балансировки нагрузки работает на уровне 4 и распределяет трафик на основе протокола или портов.

Большинство веб-приложений, использующих HTTP или HTTPS, должны использовать ресурсы и контроллеры входящего трафика Kubernetes, которые работают на уровне 7. Входящий трафик можно распределять между URL-адресами приложений и обрабатывать TLS/SSL-терминацию. Входящий трафик также позволяет сократить число IP-адресов, сопоставляемых и открываемых для доступа.

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

Схема, показывающая поток входящего трафика в кластере AKS

Для обработки входящего трафика используется два компонента:

  1. ресурс входящего трафика;
  2. контроллер входящего трафика.

Ресурс входящего трафика

Ресурс входящего трафика является манифестом YAML kind: Ingress. Он определяет хост, сертификаты и правила для маршрутизации трафика к службам, работающим в кластере AKS.

В следующем примере манифест YAML распределяет трафик для myapp.com в одну из двух служб, блога или службы storeservice, а также направляет клиента в одну службу или другую на основе URL-адреса, к который он обращается.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Контроллер входящего трафика

Контроллер входящего трафика — это управляющая программа, которая выполняется на узле AKS и отслеживает входящие запросы. Затем трафик распределяется на основе правил, определенных в ресурсе входящего трафика. Хотя наиболее распространенный контроллер входящего трафика основан на NGINX, AKS не ограничивает вас каким-либо определенным контроллером. Можно использовать Contour, HAProxy, Traefik и т. д.

Контроллеры входящего трафика должны быть запланированы на узле Linux. Используйте селектор узлов в манифесте YAML или развертывание диаграммы Helm для указания того, что ресурс должен выполняться на узле под управлением Linux. Дополнительные сведения см. в статье Использование селекторов узлов для управления планированием модулей в AKS.

Входящий трафик с помощью надстройки маршрутизации приложений

Надстройка маршрутизации приложений — это рекомендуемый способ настройки контроллера входящего трафика в AKS. Надстройка маршрутизации приложений — это полностью управляемый контроллер входящего трафика для Служба Azure Kubernetes (AKS), предоставляющий следующие функции:

  • Простая настройка управляемых контроллеров Ingress NGINX на основе контроллера входящего трафика Kubernetes NGINX.

  • Интеграция с Azure DNS для управления общедоступными и частными зонами.

  • Завершение SSL с сертификатами, хранящимися в Azure Key Vault.

Дополнительные сведения о надстройке маршрутизации приложений см. в разделе "Управляемый входящий трафик NGINX" с надстройкой маршрутизации приложений.

Защита трафика с помощью брандмауэра веб-приложений (WAF)

Рекомендации по рекомендациям

Чтобы проверять входящий трафик на наличие потенциальных атак, используйте брандмауэр веб-приложений (WAF), например брандмауэр веб-приложения Barracuda для Azure или шлюз приложений Azure. Эти сетевые ресурсы с расширенными возможностями также позволяют перенаправлять трафик за пределами обычных подключений HTTP и HTTPS или базовой функции TLS-терминации.

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

  • Разгружать часть маршрутизации трафика или обработки TLS-терминации в сетевой ресурс за пределами кластера AKS.
  • Проверять входящий трафик на наличие потенциальных атак.

Брандмауэр веб-приложений (WAF), например шлюз приложений Azure, позволяет защищать и распределять трафик для кластера AKS

Для этого дополнительного уровня безопасности брандмауэр веб-приложения (WAF) фильтрует входящий трафик. Благодаря своему набору правил Open Web Application Security Project (OWASP) отслеживает атаки, такие как межсайтовые сценарии или отравление файлов cookie. Шлюз приложений Azure (доступно в предварительной версии AKS) — это брандмауэр веб-приложений, который интегрируется с кластерами AKS, присоединяясь к этим возможностям безопасности до того, как трафик достигнет кластера AKS и приложений.

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

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

Элемент управления потоком трафика с помощью политик сети

Рекомендации по рекомендациям

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

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

Чтобы использовать политики сети, включите эту функцию при создании нового кластера AKS. Вы не можете включить политику сети в существующем кластере AKS. Заранее планируйте включение сетевой политики на необходимых кластерах.

Примечание.

Политику сети следует использовать только для узлов под управлением Linux и групп pod в AKS.

Политика сети создается в качестве ресурса Kubernetes с помощью манифеста YAML. Политики применяются к определенным модулям Pod, с использованием правил входящего и исходящего трафика, определяющих поток данных.

В следующем примере применяется политика сети к контейнерам pod с примененной к ним меткой app: backend. Правило входящего трафика разрешает трафик только из модулей pod с приложением : метка внешнего интерфейса .

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Чтобы начать работу с политиками см. статью Secure traffic between pods using network policies in Azure Kubernetes Service (AKS) (Защита трафика между контейнерами pod с использованием политик сети в Azure Kubernetes Service (AKS)).

Защищенное подключение к узлам через узел-бастион

Рекомендации по рекомендациям

Не предоставляйте возможность удаленного подключения к узлам AKS. Создайте узел-бастион (jump box) в виртуальной сети управления. Используйте узел-бастион для защищенной маршрутизации трафика в кластер AKS для задач удаленного управления.

Большинство операций в AKS можно выполнить с помощью средств управления Azure или сервера Kubernetes API. Узлы AKS доступны только в частной сети и не подключаются к общедоступному Интернету. Для подключения к узлам и выполнения обслуживания и поддержки установите маршрутизацию подключений через узел-бастион (или jump box). Убедитесь, что этот узел находится в отдельной виртуальной сети управления с безопасным пиринговым подключением к виртуальной сети кластера AKS.

Подключение к узлам AKS с помощью узла-бастиона

Кроме того, необходимо защитить сеть управления для узла бастиона. Используйте Azure ExpressRoute или VPN-шлюз для подключения к локальной сети и управления доступом с помощью групп безопасности сети.

Следующие шаги

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