Бөлісу құралы:

Общие сведения о независимом шлюзе

  • Мақала

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премия

Локальный шлюз — это необязательная контейнерная версия управляемого шлюза по умолчанию, включенного в каждую службу Управления API. Это полезно для таких сценариев, как размещение шлюзов в тех же средах, где размещаются API. Используйте локальный шлюз, чтобы улучшить поток трафика API и устранить требования к безопасности и соответствию API.

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

Общие сведения о функциях в различных предложениях шлюзов см. в разделе Шлюз API в Управлении API.

Управление гибридным и многооблачным API

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

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

Каждая служба управления API состоит из следующих ключевых компонентов:

  • Плоскость управления, представленная в виде API, используемая для настройки службы с помощью портала Azure, PowerShell и других поддерживаемых механизмов.
  • Шлюз (или плоскость данных) отвечает за использование прокси для запросов API, применение политик и сбор данных телеметрии
  • Портал разработчика, используемый разработчиками для обнаружения, изучения и подключения для использования API-интерфейсов

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

Поток трафика API без использования локальных шлюзов

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

Поток трафика API с использованием локальных шлюзов

Упаковка

Локальный шлюз доступен в виде образа контейнера Docker на основе Linux в Microsoft Artifact Registry. Его можно развернуть в Docker, Kubernetes или любом другом решении оркестрации контейнеров, работающем в локальном кластере серверов, в облачной инфраструктуре или на персональном компьютере при использовании в целях оценки и разработки. Также можно развернуть локальный шлюз в качестве расширения кластера в кластере Kubernetes с поддержкой Azure Arc.

Образы контейнеров

Мы предоставляем различные образы контейнеров для локальных шлюзов в соответствии с вашими потребностями.

Соглашение о тегах Рекомендация Пример Последовательный тег Рекомендуется для производства
{major}.{minor}.{patch} Используйте этот тег, чтобы всегда запускать одну и ту же версию шлюза 2.0.0 ❌ ✔️
v{major} Используйте этот тег, чтобы всегда запускать основную версию шлюза с каждой новой функцией и исправлением. v2 ✔️ ❌
v{major}-preview Используйте этот тег, если вы всегда хотите запустить образ контейнера Microsoft последней предварительной версии. v2-preview ✔️ ❌
latest Используйте этот тег, если вы хотите оценить локальный шлюз. latest ✔️ ❌
beta1 Используйте этот тег, если вы хотите оценить предварительные версии локального шлюза. beta ✔️ ❌

Полный список доступных тегов см. здесь.

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

Использование тегов в официальных вариантах развертывания Microsoft

Наши варианты развертывания на портале Azure используют тег v2, который позволяет клиентам использовать последнюю версию образа контейнера локального шлюза версии 2 со всеми обновлениями компонентов и исправлениями.

Примечание.

Мы предоставили команды и фрагменты YAML в качестве ссылки. Вы можете использовать более конкретный тег, если требуется.

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

Узнайте подробнее о том, как установить локальный шлюз Управления API в Kubernetes с помощью Helm.

Риск использования последовательных тегов

Последовательные теги — это теги, которые потенциально обновляются при выпуске новой версии образа контейнера. Это позволяет пользователям контейнеров получать обновления образа контейнера без необходимости обновлять развертывания.

Это означает, что вы можете параллельно запустить разные версии, не заметив этого, например при выполнении действий масштабирования после обновления тега v2.

Пример. тег v2 был выпущен с образом контейнера 2.0.0, но при выпуске 2.1.0 тег v2 будет связан уже с образом 2.1.0.

Внимание

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

Подключение к Azure

Для локальных шлюзов требуется исходящее подключение TCP/IP к Azure через порт 443. Каждый локальный шлюз должен быть связан с одной службой управления API и настроен с помощью своей плоскости управления. Локальный шлюз использует подключение к Azure в следующих целях.

  • Предоставление отчетов о состоянии путем отправки сообщений с пакетами пульса каждую минуту
  • Регулярная проверка (каждые 10 секунд) и применение обновлений конфигурации, когда они доступны
  • Отправка метрик в Azure Monitor, если она настроена
  • Отправка событий в Application Insights, если она настроена

Зависимости FQDN

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

Description Требуется для версии 1 Требуется для версии 2 Примечания.
Имя узла конечной точки конфигурации <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Пользовательские имена узлов также поддерживаются и могут использоваться вместо имени узла по умолчанию.
Общедоступный IP-адрес экземпляра Управление API ✔️ ✔️ ДОСТАТОЧНО IP-адреса основного расположения.
Общедоступные IP-адреса тега службы служба хранилища Azure ✔️ Необязательный2 IP-адреса должны соответствовать основному расположению экземпляра Управление API.
Имя узла учетной записи Хранилище BLOB-объектов Azure ✔️ Необязательный2 Учетная запись, связанная с экземпляром (<blob-storage-account-name>.blob.core.windows.net)
Имя узла учетной записи хранения таблиц Azure ✔️ Необязательный2 Учетная запись, связанная с экземпляром (<table-storage-account-name>.table.core.windows.net)
Конечные точки для Azure Resource Manager ✔️ Необязательный3 Обязательные конечные management.azure.comточки.
Конечные точки для интеграции Microsoft Entra ✔️ Необязательный4 Обязательные конечные точки и <region>.login.microsoft.com login.microsoftonline.com.
Конечные точки для интеграции с приложение Azure Insights Необязательный5 Необязательный5 Минимальные обязательные конечные точки:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
Дополнительные сведения см. в документации По Azure Monitor
Конечные точки для интеграции Центров событий Необязательный5 Необязательный5 Дополнительные сведения см. в документации по Центры событий Azure
Конечные точки для интеграции внешнего кэша Необязательный5 Необязательный5 Это требование зависит от используемого внешнего кэша.

1Для экземпляра Управление API во внутренней виртуальной сети см. сведения о подключении во внутренней виртуальной сети.
2, необходимые только в версии 2, если инспектор API или квоты используются в политиках.
3. Только при использовании проверки подлинности Microsoft Entra для проверки разрешений RBAC.
4. Требуется только при использовании проверки подлинности Microsoft Entra или связанных политик Microsoft Entra.
5. Требуется только в том случае, если компонент используется и требуется общедоступный IP-адрес, порт и сведения об имени узла.

Внимание

  • Имена узлов DNS должны быть разрешаемыми для IP-адресов, а соответствующие IP-адреса должны быть доступны.
  • Имена связанных учетных записей хранения перечислены на странице состояния подключения к сети службы на портале Azure.
  • Общедоступные IP-адреса, лежащие в основе связанных учетных записей хранения, являются динамическими и могут изменяться без уведомления.

Подключение во внутренней виртуальной сети

  • Частное подключение . Если локальный шлюз развернут в виртуальной сети, включите частное подключение к конечной точке конфигурации версии 2 из расположения локального шлюза, например с помощью частного DNS в пиринговой сети.

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

Варианты проверки подлинности

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

Вариант Рекомендации
Проверка подлинности Microsoft Entra Настройка одного или нескольких приложений Microsoft Entra для доступа к шлюзу

Управление доступом отдельно для каждого приложения

Настройка длительного срока действия секретов в соответствии с политиками вашей организации

Использование стандартных процедур Microsoft Entra для назначения или отзыва разрешений пользователя или группы приложению и смены секретов
Маркер доступа шлюза (также называемый ключом проверки подлинности) Срок действия маркера истекает каждые 30 дней и должен обновляться в контейнерах.

Поддерживается ключом шлюза, который можно поворачивать независимо (например, отменять доступ)

Повторное создание ключа шлюза делает недействительными все маркеры доступа, созданные с его помощью

Сбои подключений

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

Локальный шлюз спроектирован для "статичной работы при сбоях" и может выдерживать временный разрыв подключения к Azure. Его можно развернуть с локальной резервной копией конфигурации или без нее. В случае с резервной копией конфигурации локальные шлюзы регулярно сохраняют резервную копию последней загруженной конфигурации на постоянном томе, подключенном к контейнеру или модулю Pod.

Если резервное копирование конфигурации отключено и подключение к Azure было прервано:

  • Локальные шлюзы будут продолжать работать, используя копию конфигурации, хранящуюся в памяти
  • Остановленные локальные шлюзы не смогут запуститься

Если резервное копирование конфигурации включено и подключение к Azure было прервано:

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

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

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

Ограничения

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

  • Возобновление сеанса TLS.
  • Повторное согласование сертификата клиента Для использования проверки подлинности с помощью сертификата клиента пользователям API необходимо предоставить свои сертификаты в ходе первоначального подтверждения TLS. Чтобы обеспечить такое поведение, включите параметр "Согласование сертификата клиента" при настройке пользовательского имени узла локального шлюза (имени домена).

Протокол TLS

Внимание

Этот обзор применим только к локальному шлюзу версии 1 и версии 2.

Поддерживаемые протоколы

Локальный шлюз по умолчанию обеспечивает поддержку TLS версии 1.2.

Клиенты, использующие личные домены, могут включить TLS версии 1.0 и (или) 1.1 на уровне управления.

Доступные комплекты шифров

Внимание

Этот обзор применим только к локальному шлюзу версии 2.

Локальный шлюз использует следующие комплекты шифров для подключений клиентов и серверов:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Управляющие комплекты шифров

В версии 2.1.1 и более поздних можно управлять используемыми шифрами с помощью конфигурации:

  • net.server.tls.ciphers.allowed-suites позволяет определить разделенный запятыми список шифров, используемых для подключения TLS между клиентом API и локальным шлюзом.
  • net.client.tls.ciphers.allowed-suites позволяет определить разделенный запятыми список шифров, используемых для подключения TLS между локальным шлюзом и серверной частью.

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