Vue d’ensemble de la passerelle auto-hébergée

  • Article

S’APPLIQUE À : Développeur | Premium

La passerelle auto-hébergée est une version conteneurisée facultative de la passerelle managée par défaut incluse dans chaque service Gestion des API. Il est utile pour les scénarios tels que le placement de passerelles dans les mêmes environnements que ceux où vous hébergez vos API. Utilisez la passerelle auto-hébergée pour améliorer le flux de trafic d’API et répondre aux exigences de sécurité et de conformité des API.

Cet article explique la façon dont la fonctionnalité de passerelle auto-hébergée de Gestion des API Azure permet une gestion des API multicloud et hybrides, présente son architecture de haut niveau et met en évidence ses fonctionnalités.

Pour obtenir une vue d’ensemble des fonctionnalités sur les différentes offres de passerelle, consultez la passerelle d’API dans Gestion des API.

Gestion des API multicloud et hybrides

La fonctionnalité de passerelle auto-hébergée étend la prise en charge de Gestion des API d’environnements hybrides et multicloud, et permet aux organisations de gérer efficacement et en toute sécurité des API hébergées localement et dans des clouds à partir d’un seul service de Gestion des API dans Azure.

Avec la passerelle auto-hébergée, les clients ont la possibilité de déployer une version en conteneur du composant de la passerelle Gestion des API dans les mêmes environnements que ceux où ils hébergent leurs API. Toutes les passerelles auto-hébergées sont managées à partir du service Gestion des API avec lequel elles sont fédérées. Ainsi, les clients bénéficient d’une visibilité et d’une expérience de gestion unifiée sur l’ensemble des API internes et externes.

Chaque service Gestion des API se compose des éléments clés suivants :

  • Plan de gestion, exposé sous la forme d’une API, utilisé pour configurer le service via le Portail Azure, PowerShell et d’autres mécanismes pris en charge.
  • Passerelle (ou plan de données), qui est responsable de proxyser les demandes d’API, d’appliquer des stratégies et de collecter la télémétrie.
  • Portail des développeurs utilisé par les développeurs pour découvrir, apprendre et intégrer afin d’utiliser les API

Par défaut, tous ces composants sont déployés dans Azure, ce qui fait que tout le trafic d’API (représenté par des flèches noires pleines sur l’image suivante) passe par Azure, quel que soit l’endroit où les serveurs principaux implémentant les API sont hébergés. La simplicité opérationnelle de ce modèle a un coût : une latence accrue, des problèmes de conformité et, dans certains cas, des frais supplémentaires de transfert de données.

Flux de trafic d’API sans passerelles auto-hébergées

Le déploiement de passerelles auto-hébergées dans les mêmes environnements où sont hébergées les implémentations d’API back-end permet au trafic d’API de circuler directement vers les API back-end. Cela réduit la latence, optimise les coûts de transfert de données et assure la conformité tout en conservant les avantages d’un point unique de gestion, d’observabilité et de découverte de toutes les API au sein de l’organisation, quel que soit l’emplacement où leurs implémentations sont hébergées.

Flux de trafic d’API avec passerelles auto-hébergées

Packaging

La passerelle auto-hébergée est disponible sous forme d’image conteneur Docker basée sur Linux à partir de Microsoft Artifact Registry. Elle peut être déployée sur Docker, Kubernetes ou toute autre solution d’orchestration de conteneurs s’exécutant sur un cluster de serveurs local, sur une infrastructure cloud ou, à des fins d’évaluation et de développement, sur un ordinateur personnel. Vous pouvez également déployer la passerelle auto-hébergée en tant qu’extension de cluster sur un cluster Kubernetes avec Azure Arc.

Images de conteneur

Nous proposons une variété d’images conteneur pour les passerelles auto-hébergées afin de répondre à vos besoins :

Convention de balise Recommandation Exemple Balise continue Recommandé pour la production
{major}.{minor}.{patch} Utilisez cette balise pour toujours exécuter la même version de la passerelle 2.0.0 ❌ ✔️
v{major} Utilisez cette balise pour toujours exécuter une version majeure de la passerelle avec chaque nouvelle fonctionnalité et nouveau correctif. v2 ✔️ ❌
v{major}-preview Utilisez cette balise si vous voulez toujours exécuter notre image conteneur en préversion la plus récente. v2-preview ✔️ ❌
latest Utilisez cette balise si vous voulez évaluer la passerelle auto-hébergée. latest ✔️ ❌
beta1 Utilisez cette balise si vous voulez évaluer les versions préliminaires de la passerelle auto-hébergée. beta ✔️ ❌

Une liste complète des balises disponibles est dressée ici.

1Les versions préliminaires ne sont pas officiellement prises en charge et ne sont disponibles qu’à des fins expérimentales. Consultez les stratégies de prise en charge des passerelles auto-hébergées.

Utilisation de balises dans nos options de déploiement officielles

Nos options de déploiement dans le portail Azure utilisent la balise v2 qui permet aux clients d’utiliser la version la plus récente de l’image conteneur v2 de la passerelle auto-hébergée avec la totalité des correctifs et mises à jour de fonctionnalités.

Notes

Nous indiquons la commande et les extraits de code YAML à titre de référence, donc n’hésitez pas à utiliser une balise plus spécifique si vous le souhaitez.

Lors de l’installation avec notre chart Helm, le balisage d’image est optimisé pour vous. La version d’application du chart Helm épingle la passerelle sur une version donnée et ne s’appuie pas sur latest.

En savoir plus sur l’installation d’une passerelle auto-hébergée Gestion des API sur Kubernetes avec Helm.

Risque lié à l’utilisation de balises continues

Les balises continues sont des balises éventuellement mises à jour lors de la publication d’une nouvelle version de l’image conteneur. Elles permettent aux utilisateurs de conteneurs de recevoir des mises à jour de l’image conteneur sans avoir à mettre à jour leurs déploiements.

Cela signifie que vous pouvez éventuellement exécuter des versions différentes en parallèle sans le remarquer, notamment quand vous effectuez des actions de mise à l’échelle une fois que la balise v2 a été mise à jour.

Exemple : La balise v2 a été publiée avec l’image conteneur 2.0.0, mais au moment où 2.1.0 sera publiée, la balise v2 sera liée à l’image 2.1.0.

Important

Il est conseillé d’utiliser une étiquette de version distincte en production pour éviter toute mise à niveau involontaire vers une version plus récente.

Connectivité à Azure

Les passerelles auto-hébergées nécessitent une connectivité TCP/IP sortante vers Azure sur le port 443. Chaque passerelle auto-hébergée doit être associée à un seul service Gestion des API et est configurée via son plan de gestion. Une passerelle auto-hébergée utilise la connectivité à Azure pour les actions suivantes :

  • Signalement de son état en envoyant des messages de pulsations toutes les minutes
  • Vérification régulière (toutes les 10 secondes) et application des mises à jour de configuration chaque fois qu’elles sont disponibles
  • Envoi de métriques à Azure Monitor, si elle est configurée pour ce faire
  • Envoi d’événements à Application Insights, si elle est configurée pour ce faire

Important

La prise en charge des images conteneur de la passerelle auto-hébergée version 0 et version 1 d’Azure Gestion des API se termine le 1er octobre 2023, ainsi que son API de configuration correspondante v1. Utilisez notre guide de migration pour utiliser la passerelle auto-hébergée v2.0.0 ou une version ultérieure avec l’API de configuration v2. En savoir plus dans notre documentation de dépréciation

Dépendances de nom de domaine complet

Pour fonctionner correctement, chaque passerelle auto-hébergée a besoin d’une connectivité sortante sur le port 443 vers les points de terminaison suivants associés à son instance informatique de Gestion des API :

Description Obligatoire pour v1 Obligatoire pour v2 Notes
Nom d’hôte du point de terminaison de configuration <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Les noms d’hôte personnalisés sont également pris en charge et peuvent être utilisés à la place du nom d’hôte par défaut.
L’adresse IP publique de l’instance Gestion des API ✔️ ✔️ L’adresse IP de l’emplacement principal est suffisante.
Adresses IP publiques de l’étiquette de service Stockage Azure ✔️ Facultatif 2 Les adresses IP doivent correspondre à l’emplacement principal de Gestion des API instance.
Nom d’hôte du compte de Stockage Blob Azure ✔️ Facultatif 2 Compte associé à l’instance (<blob-storage-account-name>.blob.core.windows.net)
Nom d’hôte du compte de Stockage Table Azure ✔️ Facultatif 2 Compte associé à l’instance (<table-storage-account-name>.table.core.windows.net)
Points de terminaison pour Azure Resource Manager ✔️ Facultatif3 Les points de terminaison obligatoires sont management.azure.com.
Points de terminaison pour l’intégration Microsoft Entra ✔️ Facultatif4 Les points de terminaison obligatoires sont <region>.login.microsoft.com et login.microsoftonline.com.
Points de terminaison pour l’intégration de Azure Application Insights Facultatif5 Facultatif5 Les points de terminaison minimaux requis sont les suivants :
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
En savoir plus dans la documentation Azure Monitor
Points de terminaison pour l’intégration d’Event Hubs Facultatif5 Facultatif5 Pour en savoir plus : documents sur Azure Event Hubs
Points de terminaison pour l’intégration du cache externe Facultatif5 Facultatif5 Cette exigence dépend du cache externe utilisé

1Pour une instance Gestion des API dans un réseau virtuel interne, activez la connectivité privée au point de terminaison de la configuration v2 à partir de l’emplacement de la passerelle auto-hébergée, par exemple à l’aide d’un DNS privé dans un réseau appairé.
2Obligatoire uniquement dans v2 lorsque l’inspecteur ou les quotas d’API sont utilisés dans des stratégies.
3Requis uniquement lors de l’utilisation de l’authentification Microsoft Entra pour vérifier les autorisations RBAC.
4Uniquement requis lors de l’utilisation de l’authentification Microsoft Entra ou de stratégies associées à Microsoft Entra.
5Obligatoire uniquement lorsque la fonctionnalité est utilisée et nécessite des informations d’adresse IP publique, de port et de nom d’hôte.

Important

  • Les noms d’hôte DNS doivent pouvoir être résolus en adresses IP et les adresses IP correspondantes doivent être accessibles.
  • Les noms des comptes de stockage associés sont répertoriés dans la page État de la connectivité réseau du service dans le portail Azure.
  • Les IP publiques sous-jacentes aux comptes de stockage associés sont dynamiques et peuvent changer sans préavis.

Options d’authentification

Pour authentifier la connexion entre la passerelle auto-hébergée et le point de terminaison de configuration de l’instance Gestion des API cloud, vous disposez des options suivantes dans les paramètres de configuration du conteneur de passerelle.

Option À propos de l’installation
Authentification Microsoft Entra Configurer une ou plusieurs applications Microsoft Entra pour accéder à la passerelle

Gérer un accès de manière séparée par application

Configurer des délais d’expiration plus longs pour des secrets selon les stratégies de votre organisation

Utiliser des procédures Microsoft Entra standard pour attribuer ou révoquer des autorisations d’utilisateur ou de groupe à l’application et faire pivoter des secrets
Jeton d’accès de passerelle (également appelé clé d’authentification) Le jeton expire tous les 30 jours au maximum et doit être renouvelé dans les conteneurs

Repose sur une clé de passerelle que vous pouvez faire pivoter indépendamment (par exemple, pour révoquer un accès)

La régénération d’une clé de passerelle invalide tous les jetons d’accès créés avec elle

Échecs de connectivité

Lorsque la connectivité à Azure est perdue, la passerelle auto-hébergée ne peut plus recevoir de mises à jour de configuration, signaler son état ou charger la télémétrie.

La passerelle auto-hébergée est conçue pour « basculer en mode statique » et peut survivre à une perte temporaire de connectivité à Azure. Elle peut être déployée avec ou sans sauvegarde de configuration locale. Grâce à la sauvegarde de configuration, les passerelles auto-hébergées enregistrent régulièrement une copie de sauvegarde de la configuration téléchargée la plus récente sur un volume persistant attaché à leur conteneur ou à leur pod.

Lorsque la sauvegarde de la configuration est désactivée et que la connectivité à Azure est interrompue :

  • Les passerelles auto-hébergées en cours d’exécution continuent à fonctionner à l’aide d’une copie en mémoire de la configuration
  • Les passerelles auto-hébergées arrêtées ne peuvent pas démarrer

Lorsque la sauvegarde de la configuration est activée et que la connectivité à Azure est interrompue :

  • Les passerelles auto-hébergées en cours d’exécution continuent à fonctionner à l’aide d’une copie en mémoire de la configuration
  • Les passerelles auto-hébergées arrêtées peuvent démarrer à l’aide d’une copie de sauvegarde de la configuration

Lorsque la connectivité est restaurée, chaque passerelle auto-hébergée affectée par la panne se reconnecte automatiquement à son service Gestion des API associé et télécharge toutes les mises à jour de configuration qui se sont produites pendant que la passerelle était « hors connexion ».

Sécurité

Limites

Les fonctionnalités suivantes, présentes dans les passerelles gérées, ne sont pas disponibles dans les passerelles auto-hébergées :

  • Reprise de session TLS.
  • Renégociation du certificat client. Pour utiliser l’authentification par certificat client, les consommateurs d’API doivent présenter leurs certificats dans le cadre de l’établissement d’une liaison TLS initiale. Pour garantir ce comportement, activez le paramètre Négocier le certificat client lors de la configuration d’un nom d’hôte personnalisé pour une passerelle auto-hébergée (nom de domaine).

TLS (Transport Layer Security)

Important

Cette vue d’ensemble s’applique seulement à la passerelle auto-hébergée v1 et v2.

Protocoles pris en charge

La passerelle auto-hébergée prend en charge TLS v1.2 par défaut.

Les clients utilisant des domaines personnalisés peuvent activer TLS v1.0 et/ou v1.1 dans le plan de contrôle.

Suites de chiffrement disponibles

Important

Cette vue d’ensemble s’applique uniquement à la passerelle auto-hébergée v2.

La passerelle auto-hébergée utilise les suites de chiffrement suivantes pour les connexions client et serveur :

  • 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

Gestion des suites de chiffrement

À partir de la version 2.1.1, vous pouvez gérer les chiffrements utilisés par le biais de la configuration :

  • net.server.tls.ciphers.allowed-suites vous permet de définir une liste séparée par des virgules de chiffrements à utiliser pour la connexion TLS entre le client d’API et la passerelle auto-hébergée.
  • net.client.tls.ciphers.allowed-suites vous permet de définir une liste séparée par des virgules de chiffrements à utiliser pour la connexion TLS entre la passerelle auto-hébergée et le back-end.

Étapes suivantes