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

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

  • Статья

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

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

В этой статье объясняется, как функция самоподдерживаемого шлюза в Azure API Management позволяет осуществлять гибридное и многооблачное управление 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 Используйте этот тег, если вы всегда хотите работать с самым последним предварительным образом контейнера. v2-preview ✔️ ❌
latest Используйте этот тег, если вы хотите оценить локальный шлюз. latest ✔️ ❌
beta 1 Используйте этот тег, если вы хотите оценить предварительные версии локального шлюза. beta ✔️ ❌

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

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

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

Наши варианты развертывания на портале 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".

Описание Требуется для версии 1 Требуется для версии 2 Примечания.
Имя узла конечной точки конфигурации <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net 1 Пользовательские имена узлов также поддерживаются и могут использоваться вместо имени узла по умолчанию.
Общедоступный IP-адрес экземпляра управления API ✔️ ✔️ Адрес IP основного местоположения вполне достаточно.
Общедоступные IP-адреса тега службы хранилища Azure ✔️ Необязательный2 IP-адресы должны соответствовать основному расположению экземпляра управления API.
Имя узла учетной записи Azure Blob Storage ✔️ Необязательный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Требуется только в v2, если инспектор 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. Его можно развернуть с локальной резервной копией конфигурации или без нее. Резервное копирование конфигурации позволяет самостоятельно размещенным шлюзам регулярно сохранять резервную копию последней загруженной конфигурации на постоянном томе, подключенном к их контейнеру или модулю.

Если резервное копирование конфигурации отключено и подключение к 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 между локальным шлюзом и серверной частью.

Связанный контент