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

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

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

В этой статье объясняется, как функция локального шлюза управления API Azure обеспечивает гибридное и многооблачное управление 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 в организации, независимо от того, где размещаются их реализации.

Упаковка

Самостоятельный шлюз доступен в виде образа контейнера 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` ¹	Используйте этот тег, если вы хотите оценить предварительные версии локального шлюза.	`beta`	✔️	❌

Здесь можно найти полный список доступных тегов.

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

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

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

Примечание.

Команды и фрагменты YAML предоставляются в качестве ссылки. Если вы хотите, можно использовать более конкретный тег.

При установке шлюза с диаграммой Helm оптимизированы теги изображений. Версия приложения диаграммы 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".

Конечная точка	Обязательно?	Примечания.
Имя узла конечной точки конфигурации	`<api-management-service-name>.configuration.azure-api.net` ¹	Пользовательские имена узлов также поддерживаются и могут использоваться вместо имени узла по умолчанию.
Общедоступный IP-адрес экземпляра управления API	✔️	IP-адрес основной площадки будет достаточен.
Общедоступные IP-адреса сервисного тэга хранилища Azure	Необязательный²	IP-адреса должны соответствовать основному расположению экземпляра службы управления API.
Имя хоста учетной записи Azure Blob Storage	Необязательный²	Учетная запись, связанная с экземпляром (`<blob-storage-account-name>.blob.core.windows.net`).
Имя узла учетной записи хранения таблиц Azure	Необязательный²	Учетная запись, привязанная к экземпляру (`<table-storage-account-name>.table.core.windows.net`).
Конечные точки для Azure Resource Manager	Необязательно³	Требуемая конечная точка — `management.azure.com`.
Конечные точки для интеграции Microsoft Entra	Необязательный⁴	Обязательные конечные точки: `<region>.login.microsoft.com` и `login.microsoftonline.com`.
Конечные точки для интеграции с приложение Azure Insights	Необязательный⁵	Минимальные обязательные конечные точки: `rt.services.visualstudio.com:443dc.services.visualstudio.com:443`и `{region}.livediagnostics.monitor.azure.com:443`. Дополнительные сведения см. в документации по Azure Monitor.
Конечные точки для интеграции Центров событий	Необязательный⁵	Дополнительные сведения см. в статье Что такое Центры событий?.
Конечные точки для интеграции внешнего кэша	Необязательный⁵	Это требование зависит от используемого внешнего кэша.

¹Сведения об экземпляре управления API во внутренней виртуальной сети см. в разделе "Подключение" во внутренней виртуальной сети.
²Требуется только в v2, если инспектор API или квоты используются в политиках.
³ Только требуется при использовании проверки подлинности Microsoft Entra для подтверждения разрешений RBAC.
⁴Требуется только при использовании проверки подлинности или политик Microsoft Entra, связанных с Microsoft Entra.
⁵Требуется только в том случае, если эта функция используется и требует сведений об общедоступном IP-адресе, порту и имени узла.

Внимание

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

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

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

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

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

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

Вариант

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

Проверка подлинности Microsoft Entra

Настройте одно или несколько приложений Microsoft Entra для доступа к шлюзу.

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

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

Используйте стандартные процедуры Microsoft Entra, чтобы назначить или отозвать разрешения пользователя или группы для приложений и смены секретов.

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

Срок действия токена истекает не реже чем каждые 30 дней и должен обновляться в контейнерах.

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

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

Подсказка

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

Протокол безопасности транспортного уровня (TLS)

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

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

При использовании пользовательских доменов можно включить TLS версии 1.0 и(или) версии 1.1 в плоскости управления.

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

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

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

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-09-30