Partager via

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

S’APPLIQUE À : Développeur | Premium

La passerelle auto-hébergée est une version facultative en conteneur de la passerelle managée par défaut incluse dans chaque instance gestion des API. Il est utile pour les scénarios tels que le placement de passerelles dans les mêmes environnements 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 comment la fonctionnalité de passerelle auto-hébergée de Gestion des API Azure permet la gestion des API hybrides et multiclouds. Il présente également l’architecture de haut niveau de la fonctionnalité et décrit ses fonctionnalités.

Pour obtenir une vue d’ensemble des différences entre les passerelles gérées et auto-hébergées, 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 pour les environnements hybrides et multiclouds et vous permet de gérer efficacement et en toute sécurité les API hébergées localement et entre les clouds à partir d’une seule instance gestion des API sur Azure.

Avec la passerelle auto-hébergée, vous avez la possibilité de déployer une version conteneurisée du composant de passerelle Gestion des API dans les mêmes environnements où vous hébergez vos API. Toutes les passerelles auto-hébergées sont gérées à partir de l’instance Gestion des API avec laquelle elles sont fédérées, ce qui vous offre la visibilité et l’expérience de gestion unifiée sur toutes les API internes et externes.

Chaque instance gestion des API se compose des composants clés suivants :

  • Plan de gestion, exposé en tant qu’API, utilisé pour configurer le service via le portail Azure, PowerShell et d’autres technologies prises en charge
  • La passerelle (ou le plan de données) est responsable du proxy des requêtes d’API, de l’application des stratégies et de la collecte des données de télémétrie
  • Portail des développeurs utilisé par les développeurs pour découvrir, apprendre et intégrer à l’aide des API

Par défaut, tous ces composants sont déployés sur Azure, ce qui entraîne l’hébergement de tous les trafics d’API (illustrés sous forme de flèches noires solides dans l’image suivante) vers Azure, quel que soit l’emplacement où les back-ends implémentant les API sont hébergées. 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ù les implémentations de l’API principale sont hébergées permet au trafic d’API de circuler directement vers les API back-end, ce qui réduit la latence, optimise les coûts de transfert de données et permet la conformité tout en conservant les avantages d’avoir un seul point de gestion, d’observabilité et de découverte pour toutes les API de l’organisation, quel que soit l’emplacement où leurs implémentations sont hébergées.

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

Emballage

La passerelle auto-hébergée est disponible sous forme d’image conteneur Docker basée sur Linux à partir de Microsoft Artifact Registry. Il peut être déployé sur Docker, Kubernetes ou toute autre solution d’orchestration de conteneur s’exécutant sur un cluster de serveurs local, 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

Une variété d’images conteneur pour les passerelles auto-hébergées est disponible :

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 souhaitez toujours exécuter la dernière image conteneur d’aperçu. v2-preview ✔️ ❌
latest Utilisez cette balise si vous voulez évaluer la passerelle auto-hébergée. latest ✔️ ❌
beta 1 Utilisez cette balise si vous voulez évaluer les versions préliminaires de la passerelle auto-hébergée. beta ✔️ ❌

Vous trouverez ici une liste complète des balises disponibles.

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 les options de déploiement officielles

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

Remarque

Les extraits de commande et YAML sont fournis sous forme de référence. Vous pouvez utiliser une balise plus spécifique si vous le souhaitez.

Lorsque vous installez une passerelle avec un graphique Helm, l’étiquetage d’images est optimisé. La version d’application du chart Helm épingle la passerelle sur une version donnée et ne s’appuie pas sur latest.

Pour plus d’informations, consultez Installer 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. L’utilisation de ce type de balises permet aux utilisateurs du conteneur de recevoir des mises à jour de l’image conteneur sans avoir à mettre à jour leurs déploiements.

Lorsque vous utilisez ce type de balise, vous pouvez potentiellement exécuter différentes versions en parallèle sans le noter, par exemple lorsque vous effectuez des actions de mise à l’échelle après la mise à jour de la v2 balise.

Exemple : la v2 balise est publiée avec l’image 2.0.0 conteneur. Quand 2.1.0 sera libéré, le v2 tag sera lié à l'image 2.1.0.

Important

Envisagez d’utiliser une balise de version spécifique en production pour éviter les mises à niveau involontaires 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 à une seule instance 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 :

  • Envoyer des messages de pulsation cardiaque chaque minute pour signaler son état.
  • Vérifiez et appliquez régulièrement (toutes les 10 secondes) les mises à jour de configuration chaque fois qu’elles sont disponibles.
  • Envoi de métriques à Azure Monitor, s’il est configuré pour le faire.
  • Envoi d’événements à Application Insights, s’il est configuré pour le faire.

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 :

Point de terminaison Obligatoire ? Remarques
Nom d’hôte du point de terminaison de configuration <api-management-service-name>.configuration.azure-api.net 1 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 du Service de Stockage Azure tag de service Facultatif 2 Les adresses IP doivent correspondre à l’emplacement principal de l’instance Gestion des API.
Nom d’hôte du compte 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 Le point de terminaison requis est 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 Les points de terminaison requis minimal sont rt.services.visualstudio.com:443, dc.services.visualstudio.com:443et {region}.livediagnostics.monitor.azure.com:443. Pour plus d’informations, consultez la documentation Azure Monitor.
Points de terminaison pour l’intégration d’Event Hubs Facultatif5 Pour plus d’informations, voir la Documentation relative aux concentrateurs Azure Event Hubs.
Points de terminaison pour l’intégration du cache externe Facultatif5 Cette exigence dépend du cache externe utilisé.

1Pour plus d’informations sur une instance Gestion des API dans un réseau virtuel interne, consultez Connectivité dans un réseau virtuel interne.
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.
4Obligatoire uniquement lorsque vous utilisez l’authentification ou les stratégies Microsoft Entra 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 être résolus en adresses IP, et les adresses IP correspondantes doivent être accessibles.
  • Les noms de compte de stockage associés sont répertoriés dans la page d’état de 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.

Connectivité dans un réseau virtuel interne

  • Connectivité privée. Si la passerelle auto-hébergée est déployée dans un réseau virtuel, activez la connectivité privée vers le point de terminaison de la configuration v2 à partir de l’emplacement de la passerelle auto-hébergée, par exemple, en tirant parti d’un DNS privé dans un réseau appairé.

  • Connectivité Internet. Si la passerelle auto-hébergée doit se connecter au point de terminaison de configuration v2 via Internet, configurez un nom d’hôte personnalisé pour le point de terminaison de configuration et exposez le point de terminaison à l’aide d’Azure Application Gateway.

Options d’authentification

Les paramètres de configuration du conteneur de passerelle fournissent les options suivantes pour authentifier la connexion entre la passerelle auto-hébergée et le point de terminaison de configuration de l’instance gestion des API basée sur le cloud.

Choix Considérations
Authentification Microsoft Entra Configurez une ou plusieurs applications Microsoft Entra pour accéder à la passerelle.

Gérez l’accès séparément par application.

Configurez des délais d’expiration plus longs pour les secrets conformément aux stratégies de votre organisation.

Utilisez les procédures standard de Microsoft Entra pour attribuer ou révoquer des autorisations de l'utilisateur ou du groupe aux applications et modifier les clés secrètes.
Jeton d’accès à la passerelle. (Également appelé clé d’authentification.) Le jeton expire au moins tous les 30 jours et doit être renouvelé dans les conteneurs.

Soutenu par une clé de passerelle qui peut être pivotée indépendamment (par exemple, pour révoquer l’accès).

La régénération de la clé de passerelle invalide tous les jetons d’accès créés avec celui-ci.

Conseil / Astuce

Consultez Gestion des API Azure comme source Event Grid pour plus d’informations sur les événements Event Grid générés par une passerelle auto-hébergée lorsqu’un jeton d’accès de passerelle est proche de l’expiration ou a expiré. Utilisez ces événements pour vous assurer que les passerelles déployées sont toujours en mesure de s’authentifier auprès de leur instance gestion des API associée.

É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 continuent de fonctionner grâce à 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 fonctionnent en continu en utilisant une copie en mémoire de la configuration.
  • Les passerelles auto-hébergées arrêtées peuvent redémarrer à l’aide d’une copie de sauvegarde des paramètres.

Lorsque la connectivité est restaurée, chaque passerelle auto-hébergée affectée par la panne se reconnecte automatiquement à son instance gestion des API associée 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 disponibles dans les passerelles managé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)

Protocoles pris en charge

Les passerelles auto-hébergées prennent en charge TLS v1.2 par défaut.

Si vous utilisez des domaines personnalisés, vous pouvez activer TLS v1.0 et/ou v1.1 dans le plan de contrôle.

Suites de chiffrement disponibles

Les passerelles auto-hébergées utilisent 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

Avec v2.1.1 et versions ultérieures, vous pouvez gérer les chiffrements utilisés via la configuration :

  • net.server.tls.ciphers.allowed-suites vous permet de définir une liste séparée par des virgules de chiffrement à 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 chiffrement à utiliser pour la connexion TLS entre la passerelle auto-hébergée et le serveur principal.

Contenu connexe

  • Last updated on