Рекомендации по подключению к сети и безопасности в Azure Kubernetes Service (AKS)

Это важно

В 31 марта 2028 сеть Kubenet для Azure Kubernetes Service (AKS) будет прекращена.

Чтобы избежать сбоев в работе служб, вам необходимоперейти на наложение интерфейса Azure Container Networking Interface (CNI)до этой даты, когда больше не будут поддерживаться рабочие нагрузки на kubenet для AKS.

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

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

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

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

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

Используйте сетевую технологию 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-адреса, назначенные каждому поду.

При использовании Azure сети CNI ресурс виртуальной сети находится в отдельной группе ресурсов кластера AKS. Делегируйте разрешения удостоверению кластера AKS для доступа к этим ресурсам и управления ими. Идентификатор кластера, используемый кластером AKS, должен иметь по крайней мере разрешения Сетевой соавтор в подсети вашей виртуальной сети.

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

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

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

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

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

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

Сведения о вычислении требуемого IP-адреса см. в разделе Настройка сетей CNI в Azure 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) фильтрует входящий трафик. Используя набор правил, Проект по обеспечению безопасности веб-приложений (OWASP) следит за атаками, такими как атаки посредством межсайтового скриптинга или отравления файлов cookie. Шлюз приложений Azure для контейнеров — это WAF, который интегрируется с кластерами AKS, блокируя эти функции безопасности до того, как трафик достигнет вашего кластера AKS и приложений.

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

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

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

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

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

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

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

Примечание.

Политики сети можно использовать для узлов и подов под управлением Linux или Windows в 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

Чтобы начать работу с политиками, см. раздел Экспедирование трафика между подами с помощью сетевых политик в Azure Kubernetes Service (AKS).

Оптимизация разрешения DNS с помощью LocalDNS

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

Включите LocalDNS в пулах узлов AKS, чтобы повысить производительность DNS, надежность и уменьшить нагрузку на централизованные модули pod CoreDNS.

Разрешение DNS крайне важно для обмена данными между службами в Kubernetes. По умолчанию все запросы DNS из подов отправляются в централизованные поды CoreDNS, которые могут стать узким местом при масштабировании. AKS предлагает LocalDNS, который развертывает DNS-прокси в качестве systemd службы на каждом узле. Этот прокси-сервер обрабатывает запросы DNS локально, уменьшая количество сетевых прыжков и задержку разрешения.

LocalDNS также устраняет conntrack записи таблицы трафика DNS, предотвращая conntrack переполнение таблицы и состояния гонки, которые могут привести к разрывам соединений. Подключения из локального кэша к CoreDNS обновляются до TCP, что позволяет перебалансировать подключения и ускорить очистку записей отслеживания.

Для рабочих нагрузок, требующих высокой доступности DNS, LocalDNS поддерживает обслуживание устаревших кэшированных ответов для настраиваемой длительности при недоступности вышестоящего DNS. Эта возможность помогает поддерживать надежность подключения и обслуживания pod во время временных сбоев DNS.

Дополнительные сведения об архитектуре и возможностях LocalDNS см. в разделе "Разрешение DNS" в AKS. Инструкции по настройке см. в разделе "Настройка LocalDNS".

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

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

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

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

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

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

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