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

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

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

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

Руководство по передовым практикам

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

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

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

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

Сеть CNI

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

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

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

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

Узнайте, как рассчитать необходимый IP-адрес, в разделе Настройка сети Azure CNI в AKS.

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

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

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

Руководство по передовым практикам

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

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

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

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

Существует два компонента для входа:

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

Ресурс Ingress

Ресурс ingress представляется в виде манифеста YAML . Он определяет хост, сертификаты и правила для маршрутизации трафика к службам, работающим в кластере 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.

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

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

• Простая настройка управляемых контроллеров NGINX Ingress, основанных на Kubernetes NGINX Ingress Controller.

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

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

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

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

Руководство по передовым практикам

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

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

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

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

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

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

Управляйте потоком трафика с помощью сетевых политик

Руководство по передовым практикам

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

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

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

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

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

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.

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

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

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