Использование Брандмауэр Azure для защиты кластера Служба Azure Kubernetes (AKS)

Брандмауэр Azure

Служба Azure Kubernetes (AKS)

Приватный канал Azure

Виртуальная сеть Azure

Azure DevOps

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

Архитектура

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

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

Кластер AKS (AksSubnet).
Виртуальная машина и частные конечные точки (VmSubnet).
Шлюз приложений WAF2 (AppGatewaySubnet).
Бастион Azure (AzureBastionSubnet).

Кластер AKS использует определяемое пользователем управляемое удостоверение для создания дополнительных ресурсов, таких как подсистемы балансировки нагрузки и управляемые диски в Azure. Модули Terraform позволяют при необходимости развертывать кластер AKS, имеющий следующие функции:

Кластер AKS состоит из следующих пулов:

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

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

Узел Бастиона Azure обеспечивает улучшенное подключение SSH к виртуальной машине прыжка по протоколу SSL. Реестр контейнеров Azure используется для создания, хранения и управления образами контейнеров и артефактами (например, диаграммы Helm).

Архитектура включает в себя Брандмауэр Azure, которая используется для управления входящим и исходящим трафиком с помощью правил DNAT, правил сети и правил приложений. Она также помогает защитить рабочие нагрузки с помощью фильтрации на основе аналитики угроз. Брандмауэр Azure и Бастион развертываются в центральной виртуальной сети, которая выполняет пиринг с виртуальной сетью, в которую размещается частный кластер AKS. Таблица маршрутов и определяемые пользователем маршруты используются для маршрутизации исходящего трафика из частного кластера AKS в Брандмауэр Azure.

Примечание.

Настоятельно рекомендуется использовать номер SKU класса Premium Брандмауэр Azure, так как он обеспечивает расширенную защиту от угроз.

Хранилище ключей используется в качестве хранилища секретов рабочими нагрузками, работающими в AKS, для получения ключей, сертификатов и секретов с помощью Идентификация рабочей нагрузки Microsoft Entra драйвера CSI хранилища секретов или Dapr. Приватный канал Azure позволяет рабочим нагрузкам AKS получать доступ к службам Azure PaaS, таким как Azure Key Vault, через частную конечную точку в виртуальной сети.

Топология включает частные конечные точки и частные зоны DNS для этих служб:

Учетная запись Хранилища BLOB-объектов Azure:
Реестр контейнеров
Key Vault
Сервер API кластера Kubernetes

Существует связь между концентраторами и периферийными виртуальными сетями, в которых размещается кластер AKS, и частные зоны DNS, описанные ранее.

Рабочая область Log Analytics используется для сбора журналов и метрик диагностика из служб Azure.

Компоненты

Брандмауэр Azure — это облачная интеллектуальная служба безопасности брандмауэра сети, которая обеспечивает защиту от угроз для облачных рабочих нагрузок, работающих в Azure. Это высокодоступная служба с полным отслеживанием состояния и неограниченными возможностями облачного масштабирования. Она обеспечивает анализ внутреннего и внешнего трафика.
Реестр контейнеров — это управляемая частная служба реестра Docker, основанная на реестре Docker с открытым исходным кодом 2.0. Реестры контейнеров Azure можно использовать с существующими конвейерами разработки и развертывания контейнеров или использовать задачи реестра контейнеров для создания образов контейнеров в Azure.
Служба Azure Kubernetes упрощает развертывание управляемых кластеров Kubernetes в Azure путем разгрузки операционных расходов в Azure. Размещенная в Azure служба Kubernetes отвечает за критические задачи, в частности за мониторинг работоспособности и техническое обслуживание. Так как мастера Kubernetes управляются Azure, вы управляете только узлами агента и обслуживаете их.
Key Vault хранит и управляет доступом к секретам, таким как ключи API, пароли, сертификаты и криптографические ключи с улучшенной безопасностью. Key Vault также позволяет легко подготавливать, администрировать и развертывать общедоступные и частные сертификаты уровня безопасности и защиты сокетов (TLS/SSL) для использования с Azure и внутренними подключенными ресурсами.
Бастион Azure — это полностью управляемое решение, предоставляемое в режиме "платформа как услуга (PaaS)", которое подготавливается в виртуальной сети. Бастион Azure обеспечивает улучшенное подключение протокола удаленного рабочего стола (RDP) и Secure Shell (SSH) к виртуальным машинам в виртуальной сети непосредственно из портал Azure по протоколу TLS.
Azure Виртуальные машины предоставляет масштабируемые вычислительные ресурсы по запросу, которые обеспечивают гибкость виртуализации.
Виртуальная сеть Azure — стандартный блок для частных сетей в Azure. виртуальная сеть позволяет ресурсам Azure (например, виртуальным машинам) взаимодействовать друг с другом, Интернетом и локальными сетями с улучшенной безопасностью. Виртуальная сеть Azure похожа на традиционную сеть, которая является локальной, но включает в себя преимущества инфраструктуры Azure, такие как масштабируемость, доступность и изоляция.
интерфейсы виртуальная сеть позволяют виртуальным машинам Azure взаимодействовать с Интернетом, Azure и локальными ресурсами. На одну виртуальную машину Azure можно добавить несколько сетевых карт, поэтому дочерние виртуальные машины могут иметь собственные выделенные устройства с сетевым интерфейсом и IP-адреса.
Управляемые диски Azure предоставляют тома хранилища на уровне блоков, управляемые Azure на виртуальных машинах Azure. Доступны диски ценовой категории "Ультра", твердотельные диски уровня "Премиум" (SSD), стандартные диски SSD и жесткие диски уровня "Стандартный" (HDD).
Служба хранилища BLOB-объектов — это решение для хранения объектов в облаке. Хранилище BLOB-объектов оптимизировано для хранения больших объемов неструктурированных данных.
Приватный канал позволяет получить доступ к службам Azure PaaS (например, BLOB-объектов служба хранилища и Key Vault) через частную конечную точку в виртуальной сети. Вы также можете использовать его для доступа к размещенным в Azure службам, которые вы владеете или которые предоставляются партнером Майкрософт.

Альтернативные варианты

Вместо Брандмауэр Azure можно использовать сторонний брандмауэр из Azure Marketplace. Если это так, необходимо правильно настроить брандмауэр для проверки и разрешения или запрета входящего и исходящего трафика из кластера AKS.

Подробности сценария

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

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

Брандмауэр Azure поддерживает три разных номера SKU для поддержки широкого спектра вариантов использования и предпочтений клиентов:

Брандмауэр Azure Premium рекомендуется защитить высокочувствительные приложения, такие как обработка платежей. Она поддерживает расширенные возможности защиты от угроз, такие как вредоносные программы и проверка TLS.
Брандмауэр Azure Standard рекомендуется для клиентов, ищущих брандмауэр уровня 3–7 и которым требуется автоматическое масштабирование для обработки пиковых периодов трафика до 30 Гбит/с. Она поддерживает корпоративные функции, такие как аналитика угроз, DNS-прокси, пользовательские DNS-серверы и веб-категории.
Брандмауэр Azure Базовый рекомендуется для клиентов с потребностями пропускной способности менее 250 Мбит/с.

В следующей таблице показаны функции трех номеров SKU Брандмауэр Azure. Дополнительные сведения см. в Брандмауэр Azure ценах.

Screenshot that shows features of the three Azure Firewall SKUs

По умолчанию кластеры AKS имеют неограниченный исходящий доступ к Интернету. Этот уровень сетевого доступа позволяет узлам и службам, работающим в кластере AKS, получать доступ к внешним ресурсам по мере необходимости. Если вы хотите ограничить исходящий трафик, ограниченное количество портов и адресов должно оставаться доступным для поддержания работоспособных задач обслуживания кластера. Самый простой способ обеспечить безопасность исходящего трафика из кластера Kubernetes, например AKS, — использовать брандмауэр программного обеспечения, который может контролировать исходящий трафик на основе доменных имен. Брандмауэр Azure может ограничить исходящий трафик HTTP и HTTPS на основе полного доменного имени назначения. Вы также можете настроить правила брандмауэра и безопасности, чтобы разрешить эти необходимые порты и адреса. Дополнительные сведения см. в разделе "Управление исходящим трафиком" для узлов кластера в AKS.

Аналогичным образом можно управлять трафиком входящего трафика и повысить безопасность, включив фильтрацию на основе аналитики угроз на Брандмауэр Azure, развернутой в общей сети периметра. Эта фильтрация может предоставлять оповещения и запрещать трафик из известных вредоносных IP-адресов и доменов.

Потенциальные варианты использования

Этот сценарий устраняет необходимость повышения безопасности входящего и исходящего трафика в кластер Kubernetes и из него.

Избегайте асимметричной маршрутизации

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

Пакеты поступают на общедоступный IP-адрес брандмауэра, но возвращаются к брандмауэру через частный IP-адрес (используя маршрут по умолчанию). Это проблема. Чтобы избежать этого, создайте другой определяемый пользователем маршрут для общедоступного IP-адреса брандмауэра, как показано на следующей схеме. Пакеты, передаваемые в общедоступный IP-адрес брандмауэра, направляются через Интернет. Эта конфигурация позволяет избежать маршрута по умолчанию к частному IP-адресу брандмауэра.

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

Создайте и свяжите таблицу маршрутов с каждой подсетью, где размещаются рабочие узлы кластера.
Создайте определяемый пользователем маршрут для пересылки трафика для 0.0.0.0/0 CIDR в частный IP-адрес Брандмауэр Azure. Укажите виртуальную (модуль) для типа следующего прыжка.

Дополнительные сведения см. в учебнике Руководство по развертыванию и настройке брандмауэра Azure с помощью портала Azure.

Дополнительные сведения см. в разделе:

Развертывание рабочих нагрузок в частном кластере AKS при использовании Azure DevOps

Если вы используете Azure DevOps, обратите внимание, что для развертывания рабочих нагрузок в частном кластере AKS нельзя использовать агенты Azure DevOps, размещенные корпорацией Майкрософт. У них нет доступа к серверу API. Чтобы развернуть рабочие нагрузки в частном кластере AKS, необходимо подготовить и использовать локальный агент Azure DevOps в той же виртуальной сети, что и частный кластер AKS, или в одноранговой виртуальной сети. В последнем случае обязательно создайте связь виртуальной сети между частной зоной DNS кластера AKS в группе ресурсов узла и виртуальной сетью, где размещается локальный агент Azure DevOps.

Вы можете развернуть один агент Windows или Linux Azure DevOps на виртуальной машине или использовать масштабируемый набор виртуальных машин. Дополнительные сведения см. в разделе "Агенты масштабируемого набора виртуальных машин Azure". В качестве альтернативы можно настроить автономный агент в Azure Pipelines для запуска в контейнере Windows Server Core (для узлов Windows) или контейнера Ubuntu (для узлов Linux) с помощью Docker. Разверните его как pod с одним или несколькими реплика в частном кластере AKS. Дополнительные сведения см. в разделе:

Если подсети, на которых размещены пулы узлов частного кластера AKS, настроены для маршрутизации исходящего трафика в Брандмауэр Azure через таблицу маршрутов и определяемый пользователем маршрут, обязательно создайте соответствующие правила приложения и сети. Эти правила должны позволить агенту получать доступ к внешним сайтам для скачивания и установки таких средств, как Docker, Kubectl, Azure CLI и Helm на виртуальной машине агента. Дополнительные сведения см. в статье Запуск локального агента в Docker и сборке и развертывании агента Конвейера Azure DevOps в AKS.

Использование Брандмауэр Azure перед общедоступным Load Balancer (цен. категория

Определения ресурсов в модулях Terraform используют мета-аргумент жизненного цикла для настройки действий при изменении ресурсов Azure за пределами элемента управления Terraform. Аргумент ignore_changes используется для указания Terraform игнорировать обновления для заданных свойств ресурсов, таких как теги. Определение ресурса политики Брандмауэр Azure содержит блок жизненного цикла, чтобы предотвратить обновление ресурса Terraform при создании, обновлении или удалении одного правила. Аналогичным образом таблица маршрутов Azure содержит блок жизненного цикла, чтобы предотвратить обновление ресурса Terraform при создании, удалении или обновлении определяемого пользователем маршрута. Это позволяет управлять правилами DNAT, приложения и сети политики Брандмауэр Azure и определяемыми пользователем маршрутами таблицы маршрутов Azure за пределами элемента управления Terraform.

Пример, связанный с этой статьей, содержит конвейер Azure DevOps CD, в котором показано, как развернуть рабочую нагрузку в частном кластере AKS с помощью конвейера Azure DevOps, работающего в локальном агенте. В примере развертывается веб-приложение управления проектами Bitnami redmine с помощью общедоступной диаграммы Helm . На этой схеме показана топология сети примера:

Ниже приведен поток сообщений:

Запрос веб-приложения, размещенного в AKS, отправляется на общедоступный IP-адрес, предоставляемый Брандмауэр Azure через общедоступную IP-конфигурацию. Общедоступный IP-адрес и конфигурация общедоступных IP-адресов предназначены для этой рабочей нагрузки.
Правило DNAT Брандмауэр Azure преобразует Брандмауэр Azure общедоступный IP-адрес и порт на общедоступный IP-адрес и порт, используемый рабочей нагрузкой в общедоступной Load Balancer (цен. категория кластера AKS в группе ресурсов узла.
Подсистема балансировки нагрузки отправляет запрос одному из модулей pod службы Kubernetes, работающих на одном из узлов агента кластера AKS.
Ответное сообщение отправляется обратно в исходный вызывающий объект через определяемый пользователем маршрут. Общедоступный IP-адрес Брандмауэр Azure — это префикс адреса, а Интернет — тип следующего прыжка.
Любой исходящий вызов, инициированный рабочей нагрузкой, направляется на частный IP-адрес Брандмауэр Azure по определяемому пользователем маршруту. 0.0.0.0/0 — это префикс адреса, а виртуальный (модуль) — тип следующего прыжка.

Дополнительные сведения см. в разделе "Использование Брандмауэр Azure перед общедоступным Load Balancer (цен. категория кластера AKS".

Использование Брандмауэр Azure перед внутренним Load Balancer (цен. категория

В примере, связанном с этой статьей, приложение ASP.NET Core размещается в качестве службы кластером AKS и выполняется контроллером входящего трафика NGINX. Контроллер входящего трафика NGINX предоставляется через внутреннюю подсистему балансировки нагрузки, которая имеет частный IP-адрес в периферийной виртуальной сети, где размещается кластер AKS. Дополнительные сведения см. в статье "Создание контроллера входящего трафика" во внутреннюю виртуальную сеть в AKS. При развертывании контроллера входящего трафика NGINX или более широкой LoadBalancerClusterIPservice.beta.kubernetes.io/azure-load-balancer-internal: "true" версии с заметкой в разделе метаданных вызывается kubernetes-internal внутренняя подсистема балансировки нагрузки уровня "Стандартный" в группе ресурсов узла. Дополнительные сведения см. в разделе "Использование внутренней подсистемы балансировки нагрузки" с AKS. Как показано на следующей схеме, тестовое веб-приложение предоставляется Брандмауэр Azure через выделенный общедоступный IP-адрес Azure.

Ниже приведен поток сообщений:

Запрос веб-приложения, размещенного в AKS, отправляется на общедоступный IP-адрес, который предоставляется Брандмауэр Azure через конфигурацию общедоступного IP-адреса. Общедоступный IP-адрес и конфигурация общедоступных IP-адресов предназначены для этой рабочей нагрузки.
Правило DNAT Брандмауэр Azure преобразует Брандмауэр Azure общедоступный IP-адрес и порт в частный IP-адрес и порт, используемый контроллером входящего трафика NGINX во внутреннем Load Balancer (цен. категория кластера AKS в группе ресурсов узла.
Запрос отправляется внутренним подсистемой балансировки нагрузки одному из модулей pod службы Kubernetes, работающих на одном из узлов агента кластера AKS.
Ответное сообщение отправляется обратно в исходный вызывающий объект через определяемый пользователем маршрут. 0.0.0.0/0 — это префикс адреса, а виртуальный (модуль) — тип следующего прыжка.
Любой исходящий вызов, инициированный рабочей нагрузкой, направляется на частный IP-адрес определяемого пользователем маршрута.

Дополнительные сведения см. в разделе "Использование Брандмауэр Azure перед внутренним Load Balancer (цен. категория ".

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Некоторые из следующих рекомендаций являются общими рекомендациями, которые не относятся к использованию Брандмауэр Azure для улучшения защиты кластера AKS. Мы считаем, что они являются важными требованиями этого решения. Это относится к рекомендациям по обеспечению безопасности, производительности, доступности и надежности, хранилищу, сетке служб и мониторингу.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Платформа Azure обеспечивает улучшенную защиту от различных угроз, таких как вторжение в сеть и распределенные атаки типа "отказ в обслуживании" (DDoS). Брандмауэр веб-приложения (WAF) следует использовать для защиты всех веб-приложений и служб, размещенных в AKS, которые предоставляют общедоступную конечную точку HTTPS. Необходимо обеспечить защиту от распространенных угроз, таких как внедрение SQL, межсайтовые скрипты и другие веб-эксплойты. Для этого используйте правила open Web Application Security Project (OWASP) и настраиваемые правила. Azure Брандмауэр веб-приложений обеспечивает улучшенную централизованную защиту веб-приложений от распространенных эксплойтов и уязвимостей. Azure WAF можно развернуть с помощью Шлюз приложений Azure, Azure Front Door и Azure сеть доставки содержимого.

Атаки DDoS являются одними из крупнейших проблем доступности и безопасности, которые сталкиваются с организациями, которые перемещают свои приложения в облако. Целью DDoS-атаки является исчерпание ресурсов приложения, чтобы оно стало недоступным для обычных пользователей. Атаки DDoS могут быть нацелены на любую конечную точку, доступную через Интернет. Каждое свойство в Azure включает защиту через защиту инфраструктуры DDoS Azure без дополнительных затрат. Масштаб и емкость глобально развернутой сети Azure обеспечивает улучшенную защиту от распространенных атак сетевого уровня с помощью мониторинга трафика и устранения рисков в режиме реального времени. Защита инфраструктуры DDoS не требует изменений в конфигурации пользователя или приложения. Она помогает защитить все службы Azure, включая службы PaaS, такие как Azure DNS.

Защита сети DDoS Azure, в сочетании с рекомендациями по проектированию приложений, предоставляет расширенные функции защиты от атак DDoS. Необходимо включить защиту сети DDOS Azure в любой виртуальной сети периметра.

Ниже приведены некоторые дополнительные аспекты безопасности.

Создайте частную конечную точку для любой службы PaaS, используемой рабочими нагрузками AKS, такими как Key Vault, Служебная шина Azure и База данных SQL Azure. Трафик между приложениями и этими службами не предоставляется общедоступному Интернету. Трафик между виртуальной сетью кластера AKS и экземпляром службы PaaS через частную конечную точку передает магистральную сеть Майкрософт, но связь не проходит через Брандмауэр Azure. Этот механизм обеспечивает более высокую безопасность и лучшую защиту от утечки данных. Дополнительные сведения см. в разделе "Что такое Приватный канал Azure?".
При использовании Шлюз приложений перед кластером AKS используйте политику Брандмауэр веб-приложений для защиты общедоступных рабочих нагрузок, работающих в AKS от атак.
Используйте политики сети для разделения и защиты внутрислужбных коммуникаций, управляя тем, какие компоненты могут взаимодействовать друг с другом. По умолчанию все объекты pod в кластере Kubernetes могут отправлять и получать трафик без ограничений. Чтобы повысить безопасность, можно использовать политики сети Azure или политики сети Calico для определения правил, которые управляют потоком трафика между различными микрослужбами. Дополнительные сведения см . в разделе "Политика сети".
Не предоставляйте возможность удаленного подключения к узлам AKS. Создайте узел-бастион (jump box) в виртуальной сети управления. Используйте узел бастиона для маршрутизации трафика в кластер AKS.
Рекомендуется использовать частный кластер AKS в рабочей среде или по крайней мере безопасный доступ к серверу API с помощью авторизованных диапазонов IP-адресов в AKS. При использовании авторизованных диапазонов IP-адресов в общедоступном кластере разрешите все исходящие IP-адреса в коллекции правил сети Брандмауэр Azure. Операции в кластере используют сервер API Kubernetes.
Если вы включите DNS-прокси в Брандмауэр Azure, Брандмауэр Azure может обрабатывать и пересылать ЗАПРОСы DNS из одной или нескольких виртуальных сетей на нужный DNS-сервер. Эта функция имеет решающее значение и требуется для надежной фильтрации полного доменного имени в правилах сети. Вы можете включить DNS-прокси в параметрах брандмауэра Azure и политики брандмауэра. Дополнительные сведения о журналах прокси-сервера DNS см. в разделе Брандмауэр Azure журналов и метрик.
При использовании Брандмауэр Azure перед Шлюз приложений можно настроить ресурс входящего трафика Kubernetes для предоставления рабочих нагрузок через HTTPS и использовать отдельный поддомен и цифровой сертификат для каждого клиента. Контроллер ingress (AGIC) Шлюз приложений автоматически настраивает прослушиватель Шлюз приложений для завершения ssl-сеанса.
Вы можете использовать Брандмауэр Azure перед прокси-сервером службы, например контроллером входящего трафика NGINX. Этот контроллер предоставляет обратный прокси-сервер, настраиваемую маршрутизацию трафика и завершение TLS для служб Kubernetes. Ресурсы входящего трафика Kubernetes используются при настройке правил входящего трафика и маршрутов для отдельных служб Kubernetes. С помощью контроллера входящего трафика и правил входящего трафика можно использовать один IP-адрес для маршрутизации трафика в несколько служб в кластере Kubernetes. Сертификаты TLS можно создать с помощью распознанного центра сертификации. Кроме того, можно использовать let's Encrypt для автоматического создания сертификатов TLS с динамическим общедоступным IP-адресом или статическим общедоступным IP-адресом. Дополнительные сведения см. в статье "Создание контроллера входящего трафика HTTPS" и использование собственных сертификатов TLS в AKS.
Строгая координация между оператором Брандмауэр Azure и группами кластеров и рабочих нагрузок необходима как для первоначального развертывания кластера, так и в постоянном режиме по мере развития рабочих нагрузок и кластеров. Это особенно верно при настройке механизмов проверки подлинности, таких как OAuth 2.0 и OpenID Подключение, которые используются рабочими нагрузками для проверки подлинности своих клиентов.
Чтобы защитить среду, описанную в этой статье, используйте следующие рекомендации.

Доступность и надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".

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

Устойчивость в пределах региона

Во время развертывания можно настроить Брандмауэр Azure для охвата нескольких зон доступности для повышения доступности. Сведения об уровне обслуживания см. в Брандмауэр Azure уровне обслуживания. Вы также можете связать Брандмауэр Azure с определенной зоной ради близости, хотя эта конфигурация влияет на соглашение об уровне обслуживания. Дополнительные затраты на брандмауэр, развернутый в зоне доступности, не требуются. Однако существуют дополнительные затраты на передачу входящих и исходящих данных, связанных с зонами доступности. Дополнительные сведения см. на странице Сведения о стоимости пропускной способности.
Рассмотрите возможность развертывания пулов узлов кластера AKS во всех зонах доступности в регионе. Используйте azure Load Balancer (цен. категория или Шлюз приложений перед пулами узлов. Эта топология обеспечивает более высокую устойчивость при сбое одного центра обработки данных. Узлы кластера распределяются по нескольким центрам обработки данных в трех отдельных зонах доступности в пределах региона.
Включите избыточность зоны в реестре контейнеров для обеспечения устойчивости внутри региона и обеспечения высокого уровня доступности.
Используйте ограничения распространения топологии pod для управления распределением модулей pod по кластеру AKS между доменами сбоев, такими как регионы, зоны доступности и узлы.
Рекомендуем использовать Соглашение об уровне обслуживания с гарантией времени непрерывной работы для кластеров AKS, на которых размещены критически важные рабочие нагрузки. Соглашение об уровне обслуживания от простоя — это необязательная функция, которая обеспечивает финансовую резервную копию, более высокий уровень обслуживания для кластера. Соглашение об уровне обслуживания от простоя гарантирует высокий уровень доступности конечной точки сервера API Kubernetes для кластеров, использующих зоны доступности. Его также можно использовать для кластеров, которые не используют зоны доступности, но соглашение об уровне обслуживания ниже. Дополнительные сведения об уровне обслуживания см. в разделе об уровне обслуживания об уровне обслуживания. AKS использует реплики главного узла в доменах обновления и сбоя, чтобы обеспечить соблюдение соглашения об уровне обслуживания.

Аварийное восстановление и непрерывность бизнес-процессов

Рассмотрите возможность развертывания решения по крайней мере в двух парных регионах Azure в пределах одной географической области. Используйте глобальную подсистему балансировки нагрузки, например Диспетчер трафика Azure или Azure Front Door, с методом активной или активной или пассивной маршрутизации, чтобы гарантировать непрерывность бизнес-процессов и аварийное восстановление (аварийное восстановление).
Брандмауэр Azure — это региональная служба. При развертывании решения в двух или нескольких регионах необходимо создать Брандмауэр Azure в каждом регионе. Вы можете создать глобальную политику Брандмауэр Azure, чтобы включить в себя правила, которые применяются ко всем региональным центрам. Эту политику можно использовать в качестве родительской политики для региональных политик Azure. Политики, созданные с помощью непустых родительских политик, наследуют все коллекции правил родительской политики. Коллекции правил сети, унаследованные от родительской политики, всегда имеют приоритет над коллекциями правил сети, которые определяются как часть новой политики. Та же логика применяется к коллекциям правил приложения. Однако коллекции правил сети всегда обрабатываются перед коллекциями правил приложения независимо от наследования. Дополнительные сведения о политиках Уровня "Стандартный" и "Премиум" см. в обзоре политики диспетчера Брандмауэр Azure.
Обязательно выполняйте скрипт, документ и периодически тестируйте любой региональный процесс отработки отказа в среде качества обслуживания. Это помогает избежать непредсказуемых проблем, если основная служба влияет на сбой в основном регионе. Эти тесты также проверка, соответствует ли подход аварийного восстановления целевым объектам RPO/RTO в сочетании с конечными процессами и вмешательствами, необходимыми для отработки отказа.
Обязательно протестируйте процедуры отработки отказа, чтобы убедиться, что они работают должным образом.
Сохраните образы контейнеров в реестре контейнеров. Геоизбыточное реплика в реестре в каждом регионе AKS. Дополнительные сведения см. в статье Георепликация в Реестре контейнеров Azure.
По возможности избегайте сохранения состояния службы в контейнере. Вместо этого используйте Azure PaaS, поддерживающий многорегионные реплика tion.
Если вы используете служба хранилища Azure, подготовьте и протестируйте процесс переноса хранилища из основного региона в регион резервного копирования.

Эффективность работы

Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".

DevOps

Разверните рабочие нагрузки в AKS с помощью диаграммы Helm в конвейере непрерывной интеграции и непрерывной доставки (CI/CD). Используйте систему DevOps, например GitHub Actions или Azure DevOps. Дополнительные сведения см. в статье Сборка и развертывание в Службе контейнеров Azure.
Чтобы правильно протестировать приложение перед тем, как сделать его доступным для пользователей, используйте тестирование A/B и канаровые развертывания в управлении жизненным циклом приложений. Существует несколько техник разделения трафика между различными версиями одной и той же службы. В качестве альтернативы можно использовать возможности разделения трафика, которые становятся доступны при внедрении сетки служб. Дополнительные сведения см. в разделе Linkerd Traffic Split and Istio Traffic Management.
Для хранения частных образов Docker, развернутых в кластере, используйте Реестр контейнеров Azure или другой реестр контейнеров (например, Docker Hub). AKS может пройти проверку подлинности с помощью Реестр контейнеров Azure с помощью удостоверения Microsoft Entra.
Тестирование входящего трафика и исходящего трафика для рабочих нагрузок в отдельной предварительной среде, которая зеркало правила сетевой топологии и брандмауэра рабочей среды. Стратегия поэтапного развертывания поможет вам обнаружить все проблемы с сетью или безопасностью перед выпуском нового компонента или сетевого правила в рабочей среде.

Наблюдение

Брандмауэр Azure полностью интегрирован с Azure Monitor для ведения журнала входящего и исходящего трафика, обрабатываемого брандмауэром. Дополнительные сведения см. в статье Фильтрация на основе аналитики угроз в Брандмауэре Azure.

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

Используйте аналитику контейнеров для мониторинга состояния работоспособности кластера AKS и рабочих нагрузок.
Настройте все службы PaaS (например, реестр контейнеров и хранилище ключей) для сбора журналов диагностики и метрик.

Оптимизация затрат

Стоимость результирующей архитектуры зависит от следующих сведений о конфигурации:

Уровни службы
Масштабируемость (количество экземпляров, динамически выделяемых службами для поддержки заданного спроса)
Скрипты автоматизации
Уровень аварийного восстановления

После оценки этих сведений о конфигурации используйте калькулятор цен Azure для оценки затрат. Дополнительные варианты оптимизации ценообразования см. в принципах оптимизации затрат в Microsoft Azure Well-Architected Framework.

Развертывание этого сценария

Исходный код для этого сценария доступен в GitHub. Это решение имеет открытый исходный код и предоставляется с лицензией MIT.

Необходимые компоненты

Для сетевых развертываний требуется учетная запись Azure. Если у вас еще нет подписки Azure, создайте бесплатную учетную запись Azure, прежде чем начать работу. Перед развертыванием модулей Terraform с помощью Azure DevOps необходимо выполнить следующие требования:

Сохраните файл состояния Terraform в учетной записи хранения Azure. Дополнительные сведения об использовании учетной записи хранения для хранения удаленного состояния Terraform, блокировки состояния и шифрования неактивных данных см. в разделе "Хранилище Terraform" в служба хранилища Azure.
Создайте проект Azure DevOps. Дополнительные сведения см. в статье "Создание проекта в Azure DevOps".
Создайте подключение службы Azure DevOps к подписке Azure. При создании подключения к службе можно использовать проверку подлинности субъекта-службы (SPA) или управляемое удостоверение службы Azure. В любом случае убедитесь, что субъект-служба или управляемое удостоверение, используемое Azure DevOps для подключения к подписке Azure, назначается роль владельца всей подписки.

Развертывание в Azure

Удобные сведения о подписке Azure.

Клонируйте репозиторий Workbench GitHub:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Следуйте указаниям по установке, содержащимся в файле README.md.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Паоло Сальватори | Инженер основной службы

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Ознакомьтесь с рекомендациями и рекомендациями по AKS в Microsoft Azure Well-Architected Framework:

Использование Брандмауэр Azure для защиты кластера Служба Azure Kubernetes (AKS)