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 is a valid option for production deployments.

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

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

При использовании сети Azure CNI ресурс виртуальной сети размещается в отдельной группе ресурсов относительно кластера AKS. Delegate permissions for the AKS cluster identity to access and manage these resources. The cluster identity used by the AKS cluster must have at least Network Contributor permissions on the subnet within your virtual network.

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

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

By default, AKS uses a managed identity for its cluster identity. However, you can use a service principal instead.

• For more information about AKS service principal delegation, see Delegate access to other Azure resources.
• Для получения дополнительной информации об управляемых удостоверениях см. статью Использование управляемых удостоверений.

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

• Подсеть должна быть достаточно большой, чтобы предоставить IP-адреса для каждого узла, модуля pod и развернутого сетевого ресурса.
  • With Azure CNI networking, each running node has default limits to the number of pods.
• Старайтесь не использовать диапазоны 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 also reduces the number of IP addresses you expose and map.

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

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

1. An ingress resource
2. An ingress controller

The ingress resource is a YAML manifest of 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 и т. д.

Ingress controllers must be scheduled on a Linux node. Indicate that the resource should run on a Linux-based node using a node selector in your YAML manifest or Helm chart deployment. Дополнительные сведения см. в статье Использование селекторов узлов для управления планированием модулей в AKS.

Модуль маршрутизации приложений — это рекомендуемый способ настройки контроллера Ingress в AKS. The application routing addon is a fully managed, ingress controller for Azure Kubernetes Service (AKS) that provides the following features:

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

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

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

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

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

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

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

• Offload some of this traffic routing or TLS termination to a network resource outside of the AKS cluster.
• Проверять входящий трафик на наличие потенциальных атак.

Для этого дополнительного уровня безопасности брандмауэр веб-приложения (WAF) фильтрует входящий трафик. Благодаря своему набору правил Open Web Application Security Project (OWASP) отслеживает атаки, такие как межсайтовые сценарии или отравление файлов cookie. Azure Application Gateway (currently in preview in AKS) is a WAF that integrates with AKS clusters, locking in these security features before the traffic reaches your AKS cluster and applications.

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

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

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

Use network policies to allow or deny traffic to pods. By default, all traffic is allowed between pods within a cluster. For improved security, define rules that limit pod communication.

Политика сети — это функция Kubernetes, доступная в AKS, которая позволяет контролировать поток трафика между подами. Вы разрешаете или запрещаете трафик в pod, основываясь на таких параметрах, как назначенные метки, пространство имен или порт трафика. Network policies are a cloud-native way to control the flow of traffic for pods. Поскольку поды динамически создаются в кластере AKS, необходимые политики сети могут применяться автоматически.

Чтобы использовать политики сети, включите эту функцию при создании нового кластера AKS. Вы не можете включить политику сети в существующем кластере AKS. Plan ahead to enable network policy on the necessary clusters.

Вы создаете сетевую политику в качестве ресурса Kubernetes с помощью манифеста YAML. Policies are applied to defined pods, with ingress or egress rules defining traffic flow.

В следующем примере применяется политика сети к контейнерам 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. Create a bastion host, or jump box, in a management virtual network. Используйте узел-бастион для защищенной маршрутизации трафика в кластер AKS для задач удаленного управления.

Большинство операций в AKS можно выполнить с помощью средств управления Azure или сервера Kubernetes API. Узлы AKS доступны только в частной сети и не подключаются к общедоступному Интернету. To connect to nodes and provide maintenance and support, route your connections through a bastion host, or jump box. Verify this host lives in a separate, securely peered management virtual network to the AKS cluster virtual network.

You should also secure the management network for the bastion host. Используйте Azure ExpressRoute или VPN-шлюз для подключения к локальной сети и управления доступом с помощью групп безопасности сети.

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