Использование Брандмауэра Azure для защиты кластеров службы Azure Kubernetes Service (AKS)
В этой статье показано, как можно защитить кластеры Службы Azure Kubernetes (AKS) с помощью Брандмауэра Azure с целью обеспечения безопасности исходящего и входящего трафика.
Общие сведения
Служба Azure Kubernetes (AKS) предлагает кластер управляемой среды Kubernetes в Azure. Дополнительные сведения см. на странице Служба Azure Kubernetes.
Несмотря на то, что AKS является полностью управляемым решением, оно не предлагает встроенное решение для защиты входящего трафика и исходящего трафика между кластером и внешними сетями. Такое решение предлагает Azure Firewall.
Кластеры AKS развертываются в виртуальной сети. Эту сеть можно управлять (создать с помощью AKS) или пользовательскую (предварительно настроенную пользователем заранее). В любом случае кластер имеет исходящие зависимости от служб, находящихся за пределами этой виртуальной сети (служба не имеет входящих зависимостей). Для управления и эксплуатации узлы в кластере AKS должны получить доступ к определенным портам и полным доменным именам (FQDN), описывающим эти исходящие зависимости. Это требуется для нескольких функций, в том числе для узлов, которые взаимодействуют с сервером API Kubernetes. Они загружают и устанавливают основные компоненты кластера Kubernetes и обновления безопасности для узлов, извлекают образы базовых системных контейнеров из Реестра контейнеров Майкрософт (MCR) и так далее. Эти исходящие зависимости практически полностью определяются полным доменным FQDN, у которых нет статических адресов. Отсутствие статических адресов означает, что для блокировки исходящего из кластера AKS трафика нельзя использовать группу безопасности сети. Поэтому кластеры AKS по умолчанию имеют неограниченный исходящий доступ к Интернету. Такой уровень сетевого доступа позволяет работающим узлам и службам обращаться к внешним ресурсам по мере необходимости.
Но в рабочей среде важно защитить обмен данными с кластером Kubernetes, чтобы предотвратить кражу данных и эксплуатацию других уязвимостей. Весь входящий и исходящий сетевой трафик должен отслеживаться и контролироваться на основе набора правил безопасности. Если вы хотите сделать это, необходимо ограничить исходящий трафик, но ограниченное количество портов и адресов должно оставаться доступным для поддержания работоспособных задач обслуживания кластера и удовлетворения этих исходящих зависимостей, упомянутых ранее.
Самое простое решение — устройство брандмауэра, которое может контролировать исходящий трафик на основе доменных имен. Брандмауэр является стандартным способом создать барьер между доверенной сетью и недоверенной сетью, такой как Интернет. Брандмауэр Azure, например, может ограничить исходящий трафик HTTP и HTTPS на основе полного доменного имени назначения, обеспечивая точное управление исходящим трафиком, но в то же время позволяет предоставлять доступ к полным доменным именам, охватывающим исходящие зависимости кластера AKS (то, что группы безопасности сети не могут делать). Аналогичным образом, вы можете управлять входящим трафиком и повысить безопасность, включив фильтрацию на основе аналитики угроз на Брандмауэре Azure, развернутом в общей сети периметра. Такая фильтрация позволяет создавать оповещения и запрещать трафик, поступающий с известных вредоносных IP-адресов и доменов, или направленный к ним.
См. следующее видео, в кратком обзоре того, как это работает на практике в примере среды:
Вы можете скачать из Центра загрузки Майкрософт ZIP-файл архива, который содержит скрипт bash и YAML-файл для автоматической настройки тестовой среды, которая используется в этом видео. Он настраивает Брандмауэр Azure для защиты входящего и исходящего трафика. В следующих руководствах подробно описан каждый шаг скрипта, который позволит настроить пользовательскую конфигурацию.
На следующей схеме представлен пример среды из этого видео, который вы настроите с помощью нашего скрипта и руководства.
Существует одна разница между скриптом и приведенным ниже руководством. В скрипте используются управляемые удостоверения, а в руководстве — субъект-служба. Это два разных способа применять удостоверения для создания ресурсов кластера и управления ими.
Ограничение исходящего трафика с помощью Брандмауэра Azure
Настройка конфигурации с помощью переменных среды
Определите набор переменных среды, которые будут использоваться при создании ресурсов.
PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"
Создание виртуальной сети с несколькими подсетями
Создайте виртуальную сеть с двумя отдельными подсетями, одной для кластера, одной для брандмауэра. При необходимости можно также создать его для внутренних входных данных службы.
Создайте группу ресурсов для хранения всех ресурсов.
# Create Resource Group
az group create --name $RG --location $LOC
Создайте две виртуальные сети для размещения кластера AKS и брандмауэра Azure. Каждая из них имеет собственную подсеть. Начнем с сети AKS.
# Dedicated virtual network with AKS subnet
az network vnet create \
--resource-group $RG \
--name $VNET_NAME \
--location $LOC \
--address-prefixes 10.42.0.0/16 \
--subnet-name $AKSSUBNET_NAME \
--subnet-prefix 10.42.1.0/24
# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)
az network vnet subnet create \
--resource-group $RG \
--vnet-name $VNET_NAME \
--name $FWSUBNET_NAME \
--address-prefix 10.42.2.0/24
Создание и настройка брандмауэра Azure с использованием UDR
Необходимо настроить правила входящего и исходящего трафика брандмауэра Azure. Основное назначение брандмауэра — предоставить организациям возможность точной настройки правил входящего и исходящего трафика для кластера AKS.
Внимание
Если кластер или приложение создает большое количество исходящих подключений, направленных в одно или небольшое подмножество назначений, может потребоваться больше интерфейсных IP-адресов брандмауэра, чтобы избежать максимального количества портов на каждый интерфейсный IP. Дополнительные сведения о создании брандмауэра Azure с несколькими IP-адресами см. здесь
Создайте стандартный ресурс общедоступного IP-адреса SKU, который используется в качестве Брандмауэр Azure внешнего адреса.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Зарегистрируйте предварительную версию расширения интерфейса командной строки, чтобы создать брандмауэр Azure.
# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
Созданный ранее IP-адрес теперь можно назначить клиентскому компоненту брандмауэра.
Примечание.
Настройка общедоступного IP-адреса для брандмауэра Azure может занимать несколько минут. Чтобы использовать полное доменное имя для правил сети, необходимо включить DNS-прокси, если брандмауэр будет прослушивать порт 53 и перенаправит DNS-запросы на DNS-сервер, указанный ранее. Это позволит брандмауэру автоматически перевести полное доменное имя.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME
После выполнения предыдущей команды сохраните IP-адрес клиентского компонента брандмауэра для настройки позже.
# Capture Firewall IP Address for Later Use
FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
Примечание.
Если вы используете безопасный доступ к серверу API AKS с разрешениями диапазонов IP-адресов, необходимо добавить общедоступный IP-адрес брандмауэра в разрешенный диапазон IP-адресов.
Создание UDR с прыжком к брандмауэру Azure
Azure автоматически направляет трафик между подсетями Azure, виртуальными и локальными сетями. Если нужно изменить какой-либо из стандартных маршрутов Azure, это можно сделать с помощью создания таблицы маршрутов.
Создайте пустую таблицу маршрутов, которая будет связана с заданной подсетью. Таблица маршрутов определяет следующий прыжок как созданный ранее Брандмауэр Azure. С каждой подсетью может быть связана одна таблица маршрутов (или ноль).
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
См . документацию по таблице маршрутов виртуальной сети о переопределении системных маршрутов Azure по умолчанию или добавлении дополнительных маршрутов в таблицу маршрутов подсети.
Настройка правил брандмауэра
Примечание.
Для приложений за пределами пространств имен kube-system или gatekeeper-system, которые должны взаимодействовать с сервером API, требуется дополнительное сетевое правило, разрешающее подключение TCP к порту 443 для IP-адреса сервера API помимо добавления правила приложения для fqdn-tag AzureKubernetesService.
Для настройки брандмауэра можно использовать следующие три правила сети. Возможно, потребуется адаптировать эти правила на основе развертывания. Первое правило разрешает доступ к порту 9000 через TCP. Второе правило разрешает доступ к портам 1194 и 123 по протоколу UDP. Оба этих правила разрешают трафик, предназначенный только для CIDR региона Azure, который мы используем, в этом случае восточная часть США.
Наконец, мы добавим третье сетевое правило открытия порта 123 в полное доменное имя сервера времени Интернета (например:ntp.ubuntu.com) через UDP. Добавление полного доменного имени в качестве сетевого правила является одной из конкретных функций Брандмауэр Azure, и необходимо адаптировать его при использовании собственных параметров.
После настройки правил сети мы также добавим правило приложения с помощью AzureKubernetesService правила, охватывающего необходимые полные доменные имена, доступные через TCP-порт 443 и порт 80. Кроме того, может потребоваться настроить дополнительные правила сети и приложений на основе развертывания. Дополнительные сведения см. в разделе "Правила исходящей сети и полное доменное имя" для кластеров Служба Azure Kubernetes (AKS).
Добавление правил сети FW
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
Добавление правил приложений FW
az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
Дополнительные сведения о службе брандмауэра Azure см. в разделе Документация к брандмауэру Azure.
Привязка таблицы маршрутизации к AKS
Чтобы связать кластер с брандмауэром, выделенная подсеть для подсети кластера должна ссылаться на созданную ранее таблицу маршрутов. Привязку можно выполнить, создав команду для виртуальной сети, в которой находятся кластер и брандмауэр, чтобы обновить таблицу маршрутизации подсети кластера.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME
Развертывание AKS с типом исходящего трафика UDR в существующую сеть
Теперь кластер AKS можно развернуть в существующей виртуальной сети. Вы также используете исходящий тип userDefinedRouting, эта функция гарантирует, что исходящий трафик принудительно выполняется через брандмауэр, и другие пути исходящего трафика не существуют (по умолчанию можно использовать исходящий тип Load Balancer).
Целевая подсеть для развертывания определяется переменной среды $SUBNETID. Мы не определили переменную $SUBNETID на предыдущих шагах. Чтобы задать значение для идентификатора подсети, можно использовать следующую команду.
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
Вы определяете исходящий тип, чтобы использовать UDR, который уже существует в подсети. Эта конфигурация позволяет AKS пропускать настройку и подготовку IP-адресов для подсистемы балансировки нагрузки.
Внимание
Дополнительные сведения о типе исходящего трафика UDR, включая ограничения, см. в разделе Исходящий трафик с типом UDR.
Совет
Дополнительные функции можно добавить в развертывание кластера, например частный кластер или изменить номер SKU ОС.
Можно добавить функцию AKS для диапазонов разрешенных IP-адресов сервера API, чтобы ограничить доступ к серверу API общедоступной конечной точкой брандмауэра. Функция "диапазоны разрешенных IP-адресов" отмечается на схеме как необязательная. Если вы включаете функцию разрешенных IP-адресов для ограничения доступа на сервер API, в инструментах разработчика следует использовать инсталляционный сервер из виртуальной сети брандмауэра или добавить все конечные точки разработчика в диапазон разрешенных IP-адресов.
az aks create -g $RG -n $AKSNAME -l $LOC \
--node-count 3 \
--network-plugin azure \
--outbound-type userDefinedRouting \
--vnet-subnet-id $SUBNETID \
--api-server-authorized-ip-ranges $FWPUBLIC_IP
Примечание.
Чтобы создать и использовать собственную виртуальную сеть и таблицу маршрутов с kubenet сетевым подключаемым модулем, необходимо использовать управляемое удостоверение, назначаемое пользователем. Для управляемого удостоверения, назначаемого системой, невозможно получить идентификатор удостоверения перед созданием кластера, что приводит к задержке в назначении ролей.
Чтобы создать и использовать собственную виртуальную сеть и таблицу маршрутов с azure сетевым подключаемым модулем, поддерживаются как назначаемые системой, так и назначаемые пользователем управляемые удостоверения.
Разрешение доступа разработчика к серверу API
Если вы использовали диапазоны разрешенных IP-адресов для кластера на предыдущем этапе, необходимо добавить IP-адреса инструментария разработчика в список утвержденных диапазонов IP-адресов кластера AKS, чтобы осуществлять доступ к серверу API оттуда. Кроме того, можно настроить инсталляционный сервер с необходимым инструментарием внутри отдельной подсети в виртуальной сети брандмауэра.
Добавьте еще один IP-адрес в утвержденный диапазон, выполнив следующую команду.
# Retrieve your IP address
CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Используйте команду az aks get-credentials, чтобы настроить kubectl для подключения к только что созданному кластеру Kubernetes.
az aks get-credentials -g $RG -n $AKSNAME
Ограничение входящего трафика с помощью Брандмауэра Azure
Теперь можно приступить к раскрытию служб и развертыванию приложений в этом кластере. В этом примере мы предоставляем общедоступную службу, но вы также можете предоставить внутреннюю службу через внутреннюю подсистему балансировки нагрузки.
Ознакомьтесь с манифестом краткого руководства по демонстрации магазина AKS, чтобы просмотреть все созданные ресурсы.
Разверните службу с помощью
kubectl applyкоманды.kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/aks-store-quickstart.yaml
Добавление правила DNAT в брандмауэр Azure
Внимание
Если для ограничения исходящего трафика вы примените Брандмауэр Azure и создадите определяемый пользователем маршрут для передачи всего исходящего трафика, обязательно создайте в брандмауэре соответствующее правило DNAT, чтобы правильно пропускать входящий трафик. Использование Брандмауэра Azure в сочетании с определяемыми пользователем маршрутами нарушает передачу входящего трафика из-за асимметричной маршрутизации. (Проблема возникает, если подсеть AKS имеет маршрут по умолчанию, который переходит к частному IP-адресу брандмауэра, но вы используете общедоступную подсистему балансировки нагрузки — входящий трафик или службу Kubernetes типа: LoadBalancer). В этом случае входящий трафик подсистемы балансировки нагрузки поступает через общедоступный IP-адрес, а обратный путь проходит через частный IP-адрес брандмауэра. Так как брандмауэр отслеживает состояние и не имеет информации об активных сеансах, он отбрасывает возвращаемые пакеты. Сведения о том, как интегрировать Брандмауэр Azure с подсистемой балансировки нагрузки для входящего трафика или служб, см. в статье Интеграция Брандмауэра Azure с Azure Load Balancer (цен. категория "Стандартный").
Чтобы настроить возможность входящего подключения, необходимо записать в брандмауэр Azure правило DNAT. Чтобы проверить возможность подключения к нашему кластеру, для общедоступного IP-адреса клиентского компонента брандмауэра определяется правило, направляющего его на внутренний IP-адрес, предоставляемый внутренней службой.
Целевой адрес можно настроить, так как это порт брандмауэра, к которому осуществляется доступ. Преобразованный адрес должен представлять собой IP-адрес внутреннего балансировщика нагрузки. Преобразованный порт должен представлять собой предоставленный порт для вашей службы Kubernetes.
Необходимо указать внутренний IP-адрес, назначенный подсистеме балансировки нагрузки, созданной службой Kubernetes. Получите адрес, выполнив команду:
kubectl get services
Необходимый IP-адрес указан в столбце EXTERNAL-IP, как показано ниже.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
store-front LoadBalancer 10.41.185.82 203.0.113.254 80:32718/TCP 9m
order-service ClusterIP 10.0.104.144 <none> 3000/TCP 11s
product-service ClusterIP 10.0.237.60 <none> 3002/TCP 10s
rabbitmq ClusterIP 10.0.161.128 <none> 5672/TCP,15672/TCP 11s
Получите IP-адрес службы, выполнив:
SERVICE_IP=$(kubectl get svc store-front -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Добавьте правило NAT, выполнив команду:
az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
Проверка подключения
Перейдите к IP-адресу клиентского компонента брандмауэра Azure в браузере, чтобы проверить подключение.
Вы увидите приложение магазина AKS. В этом примере общедоступный IP-адрес брандмауэра был 203.0.113.32.
На этой странице можно просмотреть продукты, добавить их в корзину, а затем разместить заказ.
Очистка ресурсов
Чтобы очистить ресурсы Azure, удалите группу ресурсов AKS.
az group delete -g $RG
Следующие шаги
- Дополнительные сведения о службе Azure Kubernetes см. в разделе Основные понятия Kubernetes для службы Azure Kubernetes (AKS).