Partager via


Gestion des API fédérées avec des espaces de travail

S’APPLIQUE À : premium

Cet article fournit une vue d’ensemble des espaces de travail Gestion des API, et comment ils permettent aux équipes de développement d’API décentralisées de gérer et de mettre en production leurs API dans une infrastructure de service commune.

Pourquoi les organisations doivent-elles fédérer la gestion des API ?

Aujourd’hui, les organisations sont de plus en plus confrontées à des défis pour gérer la prolifération des API. Plus le nombre d’API et d’équipes de développement d’API augmente, plus leur gestion est complexe. Cette complexité peut entraîner un pic de surcharge opérationnelle, des risques de sécurité et une agilité réduite. D’un côté, les organisations souhaitent établir une infrastructure d’API centralisée pour garantir la gouvernance, la sécurité et la conformité des API. De l’autre, elles veulent que leurs équipes d’API innovent et répondent rapidement aux besoins de l’entreprise, tout en évitant la surcharge de gestion que représente une plateforme d’API.

Un modèle fédéré de gestion des API répond à ces besoins. La gestion fédérée des API permet une gestion décentralisée des API par les équipes de développement avec un isolement approprié des plans de contrôle et de données, tout en centralisant la gouvernance, le monitoring et la découverte d’API sous la responsabilité d’une équipe de plateforme d’API. Ce modèle dépasse les limitations des approches alternatives comme la gestion des API entièrement centralisée par l’équipe de plateforme ou la gestion des API en silo par chaque équipe de développement.

La gestion fédérée des API fournit :

  • Gouvernance et observabilité centralisées des API
  • Portail des développeurs unifié pour une découverte et une intégration efficaces des API
  • Autorisations administratives séparées entre les équipes d’API, pour augmenter la productivité et la sécurité
  • Runtime d’API séparé entre les équipes d’API, pour augmenter la fiabilité, la résilience et la sécurité

Comment les espaces de travail permettent une gestion fédérée des API

Dans Gestion des API Azure, utilisez des espaces de travail pour implémenter la gestion fédérée des API. Les espaces de travail fonctionnent comme des « dossiers » au sein d’un service Gestion des API :

  • Chaque espace de travail contient des API, des produits, des abonnements, des valeurs nommées et des ressources associées. Consultez la référence d’API REST de Gestion des API pour obtenir la liste complète des ressources et opérations prises en charge dans les espaces de travail.
  • L’accès des équipes aux ressources au sein d’un espace de travail est géré avec le contrôle d’accès en fonction du rôle (RBAC) d’Azure, avec des rôles intégrés ou personnalisés pouvant être attribués aux comptes Microsoft Entra et limités à un espace de travail.
  • Chaque espace de travail est associé à une ou plusieurs passerelles d’espace de travail pour router le trafic d’API vers les services de back-end d’API dans l’espace de travail.
  • L’équipe de plateforme peut appliquer des stratégies d’API couvrant les API dans les espaces de travail, monitorer la plateforme en consultant les journaux de tous les espaces de travail et implémenter une expérience de découverte d’API centralisée avec un portail des développeurs.

Diagramme conceptuel du service Gestion des API avec des espaces de travail.

Remarque

  • Les dernières fonctionnalités de l’espaces de travail sont pris en charge dans l’API REST de Gestion des API version 2023-09-01-preview ou ultérieure.
  • Pour plus de considérations sur la tarification, consultez la page Tarification d’API Management.

Bien que les espaces de travail sont gérés indépendamment du service Gestion des API et d’autres espaces de travail, ils peuvent référencer des ressources de niveau de service sélectionnées. Consultez Espaces de travail et autres fonctionnalités de Gestion des API plus loin dans cet article.

Vue d'ensemble des exemples de scénario

Une organisation qui gère des API à l’aide de Gestion des API Azure peut avoir plusieurs équipes de développement qui développent, définissent, gèrent et mettent en production différents ensembles d’API. Les espaces de travail permettent à ces équipes d’utiliser Gestion des API pour gérer, sécuriser et accéder à leurs API séparément et indépendamment de la gestion de l’infrastructure de service.

Voici un exemple de workflow pour la création et l’utilisation d’un espace de travail.

  1. Une équipe de plateforme d’API centrale qui gère l’instance de Gestion des API crée un espace de travail et affecte des autorisations aux collaborateurs de l’espace de travail à l’aide de rôles RBAC, par exemple des autorisations pour créer ou lire des ressources dans l’espace de travail. Une passerelle API limitée à l’espace de travail est également créée pour l’espace de travail.

  2. Une équipe de plateforme d’API centrale utilise les outils DevOps pour créer un pipeline DevOps pour les API dans cet espace de travail.

  3. Les membres de l’espace de travail développent, publient, mettent en production et gèrent des API dans l’espace de travail.

  4. L’équipe centrale de la plateforme d’API gère l’infrastructure du service, comme la surveillance, la résilience et l’application des stratégies de toutes les API.

Passerelle d’espace de travail

Chaque espace de travail est associé à une ou plusieurs passerelles d’espace de travail pour activer le runtime des API gérées dans l’espace de travail. La passerelle d’espace de travail est une ressource Azure autonome avec les mêmes fonctionnalités principales que la passerelle intégrée à votre service Gestion des API.

Les passerelles d’espace de travail sont gérées indépendamment entre elles ainsi que du service Gestion des API. Elles permettent d’isoler le runtime entre les espaces de travail ou les cas d’usage, d’augmenter la fiabilité, la résilience et la sécurité des API, et d’attribuer les problèmes d’exécution aux espaces de travail.

Remarque

Nous introduisons la possibilité d’associer plusieurs espaces de travail à une passerelle d’espace de travail, ce qui aide les organisations à gérer les API avec des espaces de travail à moindre coût. Cette fonctionnalité est déployée à compter de décembre 2024. Il est possible qu’elle ne soit pas disponible pour tous les services éligibles avant janvier. En savoir plus

Nom d’hôte de passerelle

Chaque association d’un espace de travail à une passerelle d’espace de travail crée un nom d’hôte unique pour les API gérées dans cet espace de travail. Les noms d’hôte par défaut suivent le modèle <workspace-name>-<hash>.gateway.<region>.azure-api.net. Actuellement, les noms d’hôte personnalisés ne sont pas pris en charge dans les passerelles d’espace de travail.

Isolement réseau

Une passerelle d’espace de travail peut éventuellement être configurée dans un réseau virtuel privé pour isoler le trafic entrant et/ou sortant. Si elle est configurée, la passerelle d’espace de travail doit utiliser un sous-réseau dédié dans le réseau virtuel.

Pour connaître les exigences détaillées, consultez Exigences de ressource réseau pour les passerelles d’espace de travail.

Remarque

  • La configuration réseau d’une passerelle d’espace de travail est indépendante de la configuration réseau de l’instance Gestion des API.
  • Actuellement, une passerelle d’espace de travail ne peut être configurée que dans un réseau virtuel lorsque la passerelle est créée. Vous ne pouvez pas modifier la configuration réseau ou les paramètres de la passerelle ultérieurement.

Mettre à l’échelle la capacité

Gérez la capacité de passerelle en ajoutant ou en supprimant manuellement des unités d’échelle, de façon similaire aux unités qui peuvent être ajoutées à l’instance Gestion des API à certains niveaux de service. Les coûts d’une passerelle d’espace de travail sont basés sur le nombre d’unités que vous sélectionnez.

Disponibilité régionale

Pour obtenir la liste actuelle des régions où les passerelles d’espace de travail sont disponibles, consultez Disponibilité des niveaux v2 et des passerelles d’espace de travail.

Contraintes de passerelle

Les contraintes suivantes s’appliquent actuellement aux passerelles d’espace de travail :

  • Une passerelle d’espace de travail doit se trouver dans la même région que la région Azure principale de l’instance Gestion des API et dans le même abonnement.
  • Un espace de travail ne peut pas être associé à une passerelle auto-hébergée
  • Les passerelles d’espace de travail ne prennent pas en charge les points de terminaison privés entrants
  • Les API dans les passerelles d’espace de travail ne peuvent pas être affectées à des noms d’hôte personnalisés
  • Les API dans les espaces de travail ne sont pas couvertes par Defender pour les API
  • Les passerelles d’espace de travail ne prennent pas en charge le gestionnaire d’informations d’identification du service Gestion des API
  • Les passerelles d’espace de travail prennent uniquement en charge le cache interne ; le cache externe n’est pas pris en charge
  • Les passerelles d’espace de travail ne prennent pas en charge les API GraphQL synthétiques et les API WebSocket
  • Les passerelles d’espace de travail ne prennent pas en charge la création d’API directement à partir de ressources Azure telles qu’Azure OpenAI Service, App Service, Function Apps, etc.
  • Les métriques de requête ne peuvent pas être fractionnées par espace de travail dans Azure Monitor ; toutes les métriques d’espace de travail sont agrégées au niveau du service
  • Les journaux Azure Monitor sont agrégés au niveau du service ; Les journaux au niveau de l’espace de travail ne sont pas disponibles
  • Les passerelles d’espace de travail ne prennent pas en charge les certificats d’autorité de certification
  • Les passerelles d’espace de travail ne prennent pas en charge la mise à l’échelle automatique
  • Les passerelles d’espace de travail ne prennent pas en charge les identités managées, notamment les fonctionnalités associées telles que le stockage de secrets dans Azure Key Vault et l’utilisation de la stratégie authentication-managed-identity

Rôles RBAC pour les espaces de travail

Azure RBAC est utilisé pour configurer les autorisations des collaborateurs de l’espace de travail pour lire et modifier des entités dans l’espace de travail. Pour obtenir la liste des rôles, consultez Guide pratique pour utiliser le contrôle d’accès en fonction du rôle dans Gestion des API.

Pour gérer les API et d’autres ressources dans l’espace de travail, les membres de l’espace de travail doivent avoir des rôles (ou des autorisations équivalentes à l’aide de rôles personnalisés) limités au service Gestion des API, à l’espace de travail et à la passerelle d’espace de travail. Le rôle étendu au service permet de référencer certaines ressources au niveau du service à partir de ressources au niveau de l’espace de travail. Par exemple, organisez un utilisateur en groupe au niveau de l’espace de travail pour contrôler la visibilité de l’API et du produit.

Remarque

Pour faciliter la gestion, configurez des groupes Microsoft Entra pour attribuer des autorisations d’espace de travail à plusieurs utilisateurs.

Espaces de travail et autres fonctionnalités de Gestion des API

Les espaces de travail sont conçus pour être autonomes afin d’optimiser la séparation des accès administratifs et du runtime d’API. Il existe plusieurs exceptions pour garantir une productivité accrue et permettre la gouvernance à l’échelle de la plateforme, l’observabilité, la réutilisation et la découverte d’API.

  • Références de ressources : les ressources d’un espace de travail peuvent référencer d’autres ressources de l’espace de travail et les ressources sélectionnées au niveau du service, comme les utilisateurs, les serveurs d’autorisation ou les groupes d’utilisateurs intégrés. Elles ne peuvent pas référencer les ressources d’un autre espace de travail.

    Pour des raisons de sécurité, il n’est pas possible de référencer des ressources au niveau du service à partir de stratégies au niveau de l’espace de travail (par exemple, des valeurs nommées) ou par des noms de ressource, comme backend-id dans la stratégie set-backend-service.

    Important

    Toutes les ressources d’un service Gestion des API (par exemple les API, les produits, les étiquettes ou les abonnements) doivent avoir des noms uniques, même si elles sont dans différents espaces de travail. Il ne peut pas y avoir de ressources du même type et avec le même nom de ressource Azure dans le même espace de travail, dans d’autres espaces de travail ou au niveau du service.

  • Portail des développeurs : les espaces de travail sont un concept administratif et ne sont pas exposés en tant que tels pour les consommateurs du portail des développeurs, notamment via l’interface utilisateur du portail des développeurs et l’API sous-jacente. Les API et les produits au sein d’un espace de travail peuvent être publiés sur le portail des développeurs, tout comme les API et les produits au niveau du service.

    Remarque

    Gestion des API prend en charge l’attribution de serveurs d’autorisation définis au niveau du service aux API au sein des espaces de travail.

Migration depuis des espaces de travail en préversion

Si vous avez créé des espaces de travail en préversion dans Azure Gestion des API et que vous souhaitez continuer à les utiliser, migrez vos espaces de travail vers la version en disponibilité générale en associant une passerelle d’espace de travail à chaque espace de travail.

Pour plus d’informations et pour en savoir plus sur les autres modifications susceptibles d’affecter vos espaces de travail en préversion, consultez Changements majeurs des espaces de travail (mars 2025).

Supprimer un espace de travail

La suppression d’un espace de travail supprime toutes ses ressources enfants (API, produits, et ainsi de suite) et sa passerelle associée, si vous supprimez l’espace de travail à l’aide de l’interface du portail Azure. Elle ne supprime pas l’instance Gestion des API ou d’autres espaces de travail.