Поделиться через

Подготовка к развертыванию рабочей нагрузки веб-приложения Amazon Web Services (AWS) в Azure

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

Развертывание Yelb в AWS

Пример веб-приложения Yelb в AWS развертывается с помощью Bash, AWS CLI, eksctl, kubectl и Helm. Пример сопроводительного материала содержит скрипты Bash и манифесты YAML, которые можно использовать для автоматизации развертывания приложения Yelb в AWS Elastic Kubernetes Service (EKS). Это решение демонстрирует, как реализовать брандмауэр веб-приложения с помощью AWS WAF для защиты веб-приложения, работающего в Amazon Elastic Kubernetes Service (EKS). Скрипты Bash можно использовать для создания кластера EKS и развертывания приложения Yelb . Веб-приложение Yelb предоставляется в общедоступном Интернете с помощью Amazon Application Load Balancer (ALB) и защищено с помощью списка управления веб-доступом AWS WAF (веб-ACL). Подробные инструкции см. в статье Перенос веб-приложения из службы AWS Elastic Kubernetes (EKS) в службу Azure Kubernetes (AKS).

Снимок экрана: интерфейс службы Yelb.

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

В следующих разделах вы узнаете, как развернуть пример веб-приложения Yelb в кластере Службы Azure Kubernetes (AKS) и предоставить его через контроллер входящего трафика, например контроллер входящего трафика NGINX. Служба контроллера входящего трафика доступна через внутреннюю (или частную) подсистему балансировки нагрузки, которая балансирует трафик в виртуальной сети, где находится кластер AKS. В гибридном сценарии внешний интерфейс подсистемы балансировки нагрузки можно получить из локальной сети. Дополнительные сведения о внутренней балансировке нагрузки см. в статье "Использование внутреннего балансировщика нагрузки" со службой Azure Kubernetes (AKS).

Пример компаньона поддерживает установку управляемого контроллера входящего трафика NGINX с надстройкой маршрутизации приложений или неуправляемым контроллером входящего трафика NGINX с помощью диаграммы Helm. Надстройка маршрутизации приложений с контроллером входящего трафика NGINX предоставляет следующие функции:

Для других конфигураций

Чтобы повысить безопасность, приложение Yelb защищено ресурсом шлюза приложений Azure . Этот ресурс развертывается в выделенной подсети в той же виртуальной сети, что и кластер AKS или в одноранговой виртуальной сети. Брандмауэр веб-приложений Azure (WAF) защищает доступ к веб-приложению, размещённому в службе Azure Kubernetes (AKS) и выставленному через шлюз приложений Azure от распространённых эксплойтов и уязвимостей.

Предпосылки

Архитектура

В этом примере представлена коллекция шаблонов Bicep, скриптов Bash и манифестов YAML для создания кластера AKS, развертывания приложения Yelb, предоставления службы пользовательского интерфейса с помощью контроллера входящего трафика NGINX и защиты ее с помощью шлюза приложений Azure и брандмауэра веб-приложений Azure (WAF).

Этот пример также включает два отдельных файла параметров Bicep и два набора скриптов Bash и манифесты YAML, каждый из которых предназначен для развертывания двух различных вариантов решения. Дополнительные сведения о Bicep см. в разделе "Что такое Bicep?"

Завершение TLS на шлюзе приложений и вызов Yelb через HTTP.

В этом решении брандмауэр веб-приложений Azure (WAF) обеспечивает безопасность системы, блокируя вредоносные атаки. Шлюз приложений Azure получает входящие вызовы от клиентских приложений, выполняет завершение TLS и пересылает запросы в размещенную yelb-ui службу AKS. Эта связь достигается с помощью внутреннего подсистемы балансировки нагрузки и контроллера входящего трафика NGINX с помощью протокола транспорта HTTP. На следующей схеме показана архитектура:

Схема решения на основе контроллера входящего трафика ШЛЮЗа приложений WAFv2 и NGINX через HTTP.

Поток сообщений выглядит следующим образом:

Схема потока сообщений решения на основе шлюза приложений WAFv2 и контроллера входящего трафика NGINX через HTTP.

  1. Шлюз приложений Azure обрабатывает завершение TLS и отправляет входящие вызовы в службу, размещенную yelb-ui в AKS, по протоколу HTTP.
  2. Прослушиватель шлюза приложений использует SSL-сертификат, полученный из Azure Key Vault , для обеспечения безопасного взаимодействия.
  3. Политика WAF Azure, связанная с прослушивателем, применяет правила OWASP и настраиваемые правила к входящим запросам, эффективно предотвращая многие типы вредоносных атак.
  4. Внутренние параметры HTTP шлюза приложений вызывают приложение Yelb через HTTP с помощью порта 80.
  5. Серверный пул шлюза приложений и проба работоспособности вызывают контроллер входящего трафика NGINX через внутреннюю подсистему балансировки нагрузки AKS с помощью протокола HTTP для управления трафиком.
  6. Контроллер входящего трафика NGINX использует внутреннюю подсистему балансировки нагрузки AKS для обеспечения безопасного взаимодействия в кластере.
  7. Объект входящего трафика Kubernetes использует контроллер входящего трафика NGINX для предоставления приложения через HTTP через внутреннюю подсистему балансировки нагрузки.
  8. yelb-ui Служба типа ClusterIP ограничивает выполнение в пределах кластера или через контроллер входящего трафика NGINX.

Реализация сквозного TLS с помощью шлюза приложений Azure

завершение сеанса TLS;

Шлюз приложений Azure поддерживает завершение TLS на уровне шлюза, что означает, что трафик расшифровывается на шлюзе перед отправкой на внутренние серверы. Чтобы настроить завершение TLS, необходимо добавить TLS/SSL-сертификат в прослушиватель. Сертификат должен находиться в формате PFX, который содержит как закрытые, так и открытые ключи. Сертификат можно импортировать из Azure Key Vault в шлюз приложений. Дополнительные сведения см. в статье о завершении TLS-подключений с использованием сертификатов из Key Vault.

Модель безопасности нулевого доверия

При внедрении модели безопасности нулевого доверия следует предотвратить незашифрованное взаимодействие между прокси-сервером службы, например шлюзом приложений Azure и серверными серверами. При использовании модели безопасности "Нулевое доверие" доверие не предоставляется пользователю или устройству, пытающимся получить доступ к ресурсам в сети. Вместо этого требуется непрерывная проверка удостоверений и авторизации для каждого запроса независимо от расположения или сети пользователя. В нашем сценарии реализация модели безопасности "Нулевое доверие" включает использование шлюза приложений Azure в качестве прокси-сервера службы, который выступает в качестве внешнего интерфейса для входящих запросов. Затем эти запросы отправляются к контроллеру входящего трафика NGINX в службе Azure Kubernetes (AKS) в зашифрованном формате.

Сквозной протокол TLS с помощью шлюза приложений

Вы можете реализовать подход "Нулевое доверие", настроив шлюз приложений Azure для сквозного шифрования TLS с внутренними серверами. Сквозное шифрование TLS позволяет безопасно передавать конфиденциальные данные в серверную часть, используя функции балансировки нагрузки на уровне 7 шлюза приложений, включая привязку сеансов на основе файлов cookie, маршрутизацию по URL, маршрутизацию по сайтам, а также возможность перезаписывать или внедрять заголовки X-Forwarded-*.

Если шлюз приложений настроен с использованием сквозного режима связи TLS, он завершает сеансы TLS на шлюзе и расшифровывает трафик пользователя. Затем он применяет настроенные правила, чтобы выбрать соответствующий экземпляр внутреннего пула для маршрутизации трафика. Затем шлюз приложений инициирует новое подключение TLS к внутреннему серверу и повторно шифрует данные с помощью сертификата открытого ключа внутреннего сервера перед передачей запроса в серверную часть. Ответ от веб-сервера следует тому же процессу, прежде чем достичь конечного пользователя. Чтобы включить сквозной протокол TLS, необходимо задать параметр протокола в параметре HTTP серверной части для HTTPS и применить его к внутреннему пулу. Такой подход гарантирует, что обмен данными с внутренними серверами обеспечивается и соответствует вашим требованиям.

Дополнительные сведения см. в разделе сквозное шифрование TLS шлюза приложений и рекомендации по защите шлюза приложений.

В этом решении брандмауэр веб-приложений Azure (WAF) обеспечивает безопасность системы, блокируя вредоносные атаки. Шлюз приложений Azure обрабатывает входящие вызовы из клиентских приложений, выполняет завершение TLS и реализует сквозную TLS, обращаясь к базовой службе, размещенной в AKS, с помощью транспортного протокола HTTPS через внутренний балансировщик нагрузки и контроллер входящего трафика NGINX. На следующей схеме показана архитектура:

Схема решения на основе контроллера входящего трафика ШЛЮЗа приложений WAFv2 и NGINX через HTTPS.

Поток сообщений выглядит следующим образом:

  1. Шлюз приложений Azure обрабатывает завершение TLS и взаимодействует с серверным приложением по протоколу HTTPS.
  2. Прослушиватель шлюза приложений использует SSL-сертификат, полученный из Azure Key Vault.
  3. Политика WAF Azure, связанная с прослушивателем, запускает правила OWASP и настраиваемые правила для входящих запросов, чтобы блокировать вредоносные атаки.
  4. Параметры HTTP серверной части шлюза приложений настроены для вызова размещенной yelb-ui службы AKS через HTTPS через порт 443.
  5. Серверный пул шлюза приложений и проба работоспособности вызывают контроллер входящего трафика NGINX через внутреннюю подсистему балансировки нагрузки AKS с помощью HTTPS.
  6. Контроллер входящего трафика NGINX развертывается для использования внутренней подсистемы балансировки нагрузки AKS.
  7. Кластер SAKS настроен с использованием поставщика Azure Key Vault для дополнения Secrets Store CSI Driver для извлечения секретов, сертификатов и ключей из Azure Key Vault через том CSI.
  8. Класс SecretProviderClass используется для получения сертификата, используемого шлюзом приложений из Key Vault.
  9. Объект ingress Kubernetes использует контроллер ingress NGINX для предоставления доступа к приложению через HTTPS через внутренний балансировщик нагрузки AKS.
  10. Служба yelb-ui имеет ClusterIP тип, который ограничивает его вызов в кластере или через контроллер входящего трафика NGINX.

Чтобы обеспечить безопасность и стабильность системы, рассмотрите следующие рекомендации:

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

Hostname (Имя узла)

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

  • Сохранение состояния сеанса: при использовании другого имени узла для прокси-сервера и серверного приложения состояние сеанса может быть потеряно. Это означает, что сеансы пользователей могут не сохраняться должным образом, что приводит к плохому опыту пользователя и потенциальному потере данных.
  • Сбой проверки подлинности: если имя хоста отличается у прокси-сервера и серверного приложения, механизмы проверки подлинности могут не сработать. Такой подход может привести к тому, что пользователи не могут войти в систему или получить доступ к безопасным ресурсам в приложении.
  • Непреднамеренное раскрытие URL-адресов: если имя хоста не сохраняется, существует риск предоставления внутренних URL-адресов конечным пользователям. Это может привести к потенциальным уязвимостям безопасности и несанкционированным доступом к конфиденциальной информации.
  • Проблемы с файлами cookie: файлы cookie играют важную роль в обслуживании сеансов пользователей и передаче информации между клиентом и сервером. Если имя узла отличается, файлы cookie могут работать неправильно, что приводит к таким проблемам, как сбой проверки подлинности, неправильное обработка сеансов и неправильное перенаправление.
  • Сквозные требования TLS/SSL. Если для безопасного обмена данными между прокси-сервером и серверной службой требуется сквозное подключение TLS/SSL, необходим соответствующий сертификат TLS для исходного имени узла. Использование того же имени узла упрощает процесс управления сертификатами и гарантирует, что безопасное взаимодействие устанавливается без проблем.

Эти проблемы можно избежать с помощью того же имени узла для прокси-сервера службы и серверного веб-приложения. Серверное приложение видит тот же домен, что и веб-браузер, обеспечивая правильность обработки состояния сеанса, проверки подлинности и URL-адреса.

Поток сообщений

На следующей схеме показаны шаги для потока сообщений во время развертывания и среды выполнения.

Схема потока сообщений решения на основе шлюза приложений WAFv2 и контроллера входящего трафика NGINX через HTTPS.

Рабочий процесс развертывания

Ниже описан процесс развертывания. Этот рабочий процесс соответствует зеленым числам на предыдущей схеме.

  1. Инженер безопасности создает сертификат для личного домена, который использует рабочая нагрузка, и сохраняет его в хранилище ключей Azure. Вы можете получить действительный сертификат из известного центра сертификации (ЦС).
  2. Инженер платформы указывает необходимые сведения в файле параметров main.bicepparams Bicep и развертывает шаблоны Bicep для создания ресурсов Azure. Необходимые сведения включают:
    • Префикс для ресурсов Azure.
    • Имя и группа ресурсов существующего хранилища ключей Azure, в котором хранится сертификат TLS для имени узла рабочей нагрузки и настраиваемого домена слушателя Application Gateway.
  3. Скрипт развертывания можно настроить для установки следующих пакетов в кластер AKS. Для получения дополнительных сведений см. раздел параметров модуля Bicep.
  4. Прослушиватель шлюза приложений получает сертификат TLS из Azure Key Vault.
  5. Объект входящего трафика Kubernetes использует сертификат, полученный от поставщика Azure Key Vault для драйвера CSI хранилища секретов, чтобы предоставить службу пользовательского интерфейса Yelb через HTTPS.
  6. Прослушиватель шлюза приложений извлекает сертификат TLS из Хранилища ключей Azure.
  7. Объект входящего трафика Kubernetes использует сертификат, полученный от поставщика Azure Key Vault для драйвера CSI хранилища секретов, чтобы предоставить службу пользовательского интерфейса Yelb через HTTPS.

Рабочий процесс выполнения

  1. Клиентское приложение вызывает пример веб-приложения с помощью имени узла. Зона DNS, связанная с личным доменом прослушивателя шлюза приложений, использует A запись для разрешения DNS-запроса с адресом общедоступного IP-адреса Azure, используемого интерфейсной IP-конфигурацией шлюза приложений.
  2. Запрос отправляется в общедоступный IP-адрес Azure, используемый интерфейсной IP-конфигурацией шлюза приложений.
  3. Шлюз приложений выполняет следующие действия:
    1. Шлюз приложений обрабатывает завершение TLS и взаимодействует с серверным приложением по протоколу HTTPS.
    2. Прослушиватель шлюза приложений использует SSL-сертификат, полученный из Azure Key Vault.
    3. Политика WAF Azure, связанная с прослушивателем, запускает правила OWASP и пользовательские правила для входящего запроса и блокирует вредоносные атаки.
    4. Параметры HTTP серверной части шлюза приложений настраиваются для вызова примера веб-приложения через HTTPS через порт 443.
  4. Серверный пул шлюза приложений вызывает контроллер входящего трафика NGINX через внутреннюю подсистему балансировки нагрузки AKS с помощью HTTPS.
  5. Запрос отправляется на один из узлов агента, на котором размещен модуль pod контроллера входящего трафика NGINX.
  6. Одна из реплик контроллера входящего трафика NGINX обрабатывает запрос и отправляет запрос в одну из конечных yelb-ui точек службы.
  7. yelb-ui вызывает yelb-appserver службу.
  8. yelb-appserver вызывает службы yelb-db и yelb-cache.
  9. yelb-ui вызывает yelb-appserver службу.
  10. yelb-appserver вызывает службы yelb-db и yelb-cache.

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

По умолчанию шаблоны Bicep устанавливают кластер AKS с сетевым плагином Azure CNI Overlay и посредством плоскости управления Cilium. Можно использовать альтернативный сетевой плагин. Кроме того, в проекте показано, как развернуть кластер AKS со следующими расширениями и функциями:

В рабочей среде настоятельно рекомендуется развертывать частный кластер AKS с соглашением об уровне обслуживания uptime. Дополнительные сведения см. в частном кластере AKS с общедоступным DNS-адресом.

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

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

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

Развертывание рабочей нагрузки веб-приложения AWS в Azure

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие участники первоначально написали его:

Основной автор:

Другие участники: