Que sont les politiques d'API Gateway ?

Avec le développement du cloud-native et de l'architecture microservices, le rôle des passerelles API en tant que portails de trafic devient de plus en plus crucial. Les passerelles API sont principalement responsables de la réception du trafic de requêtes et de leur redirection vers les services en amont appropriés. Les politiques des passerelles API déterminent la logique et les règles de gestion du trafic, ce qui influence directement le comportement du trafic métier.

Que sont les politiques des passerelles API ?

La passerelle API est généralement située devant tous les services en amont. Lorsqu'un utilisateur envoie une requête à un service, celle-ci passe d'abord par la passerelle API, qui vérifie généralement plusieurs éléments :

1. Vérifie si la requête est légale. Provient-elle d'une liste d'utilisateurs interdits d'accès ?
2. Vérifie si la requête est authentifiée et si le contenu demandé est autorisé.
3. Vérifie si la requête déclenche des règles de restriction spécifiques, comme des limites de débit.
4. Détermine à quel service en amont la requête doit être redirigée.

Après cette série d'étapes, la requête est soit rejetée, soit correctement acheminée vers le service en amont spécifié. Nous appelons ces règles de traitement les politiques de la passerelle API. Ces règles sont continuellement ajoutées à la passerelle par l'administrateur pendant son fonctionnement. La passerelle accepte ces règles et adopte des comportements de traitement du trafic en conséquence.

Prenons l'exemple de la passerelle API Apache APISIX. Il existe deux types d'informations de configuration pour APISIX : le fichier de configuration pour le démarrage de la passerelle, comme config.yaml, qui détermine certaines configurations nécessaires au démarrage normal de la passerelle. En outre, les administrateurs peuvent créer dynamiquement diverses règles et configurations via l'Admin API pendant l'exécution, comme les routes, les consommateurs, les plugins, etc. Les politiques de la passerelle API sont les différentes règles et configurations créées dynamiquement par l'administrateur via l'Admin API.

Cet article détaillera les scénarios des quatre types de politiques des passerelles API : l'authentification et l'autorisation, la sécurité, le traitement du trafic et l'observabilité, ainsi que le fonctionnement des politiques de passerelle API dans chaque scénario.

Politique d'authentification et d'autorisation

L'authentification permet de confirmer l'identité de l'appelant de l'API, tandis que l'autorisation restreint l'appelant à n'accéder qu'aux ressources dans les limites de ses droits.

Par exemple, si un passager se rend à une gare, il utilisera sa carte d'identité pour "s'authentifier" et confirmer son identité avant d'entrer dans la gare. Après être entré, il montrera son billet au personnel pour confirmation et sera "autorisé" à monter dans un train spécifique. L'objectif principal des politiques d'authentification et d'autorisation est de s'assurer que toutes les requêtes redirigées vers les services en amont sont légales et que les requêtes n'accèdent qu'aux ressources dans les limites de leurs droits. Voici quelques politiques courantes :

Authentification de base (Basic Auth)

La politique Basic Access Authentication est la technique de contrôle d'accès la plus simple. Généralement, le proxy HTTP de l'utilisateur inclut un en-tête de requête pour l'authentification, généralement sous la forme : Authorization: Basic <credentials>, où les credentials incluent l'identifiant et le mot de passe de l'utilisateur, séparés par :. Cette méthode ne nécessite pas de configurations complexes comme des pages de connexion ou des cookies. Elle est basée sur des informations d'identification simples dans l'en-tête de la requête, généralement un nom d'utilisateur et un mot de passe, ce qui la rend simple à configurer et à utiliser.

Un exemple de requête cURL avec authentification de base est le suivant, avec username et password :

curl -i -u 'username:password' http://127.0.0.1:8080/hello

Il est important de noter que les informations dans credentials ne sont pas chiffrées pendant la transmission. Elles sont uniquement encodées en base64, donc il est généralement nécessaire d'utiliser HTTPS pour garantir la sécurité du mot de passe.

Une fois cette politique mise en place dans la passerelle, les requêtes sans informations d'identification ne seront pas redirigées, sauf si elles contiennent les bonnes informations d'authentification. Cette politique permet de vérifier l'accès à l'API à moindre coût.

Authentification par clé (Key Auth)

La politique Key Auth restreint les appels d'API en ajoutant des clés à l'API et en utilisant ces clés pour contrôler l'accès aux ressources. Seules les requêtes avec la clé correcte, qui peut être incluse dans l'en-tête ou la requête, peuvent accéder aux ressources. Généralement, cette clé peut également être utilisée pour distinguer différents appelants d'API, permettant ainsi de mettre en œuvre des politiques ou des contrôles de ressources différents pour différents appelants. Comme pour l'authentification de base, la clé n'est pas chiffrée. Assurez-vous que la requête utilise HTTPS pour garantir la sécurité.

Prenons l'exemple du plugin key-auth d'APISIX. Le plugin nécessite de créer un Consumer avec une valeur de clé unique via l'Admin API :

curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack-key"
        }
    }
}'

Cette requête crée un Consumer nommé jack avec la clé jack-key.

Lors de l'activation du plugin dans la route, vous devez configurer l'emplacement et le nom du champ de la clé dans la requête. La configuration par défaut est header et le nom du champ est apikey, donc le code correct pour demander cette route est :

curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'

Une fois que APISIX reçoit cette requête, il extrait la clé et la compare avec celle du Consumer jack. Ainsi, la passerelle sait que la requête a été envoyée par jack. Si aucune clé correspondante n'est trouvée, la requête est considérée comme illégale.

JSON Web Token (JWT)

JSON Web Token (JWT) est un standard ouvert qui définit une manière sécurisée de transmettre des informations entre parties sous forme d'objets JSON. La politique JWT peut combiner authentification et autorisation. Après l'autorisation de l'utilisateur, un token JWT est transmis à l'utilisateur, et l'appelant inclut ce token dans toutes les requêtes suivantes pour s'assurer que la requête est autorisée.

Dans la passerelle API, l'authentification JWT peut être ajoutée via la politique JWT. Ainsi, nous pouvons séparer la logique d'authentification du code métier, permettant aux développeurs de se concentrer davantage sur la mise en œuvre de la logique métier. Prenons l'exemple du plugin jwt-auth d'APISIX. Le plugin doit être activé et configuré dans le Consumer avec sa clé unique, ses clés publiques et privées pour le chiffrement, l'algorithme de chiffrement, la durée de validité du token, etc. En même temps, vous devez activer ce plugin dans la route et configurer la passerelle pour lire l'emplacement et les champs du token, comme l'en-tête, la requête, le cookie, etc. Ce plugin ajoute une API à la passerelle API pour émettre des tokens. Avant d'envoyer la requête, l'API qui émet le token doit être appelée. Le token doit être inclus à l'emplacement spécifié selon les informations de configuration lors de l'envoi de la requête. Une fois que la requête atteint la passerelle, celle-ci lit le token à l'emplacement spécifié et vérifie sa validité. La requête peut être redirigée vers le service en amont après vérification.

Comparé aux deux stratégies précédentes, la politique JWT inclut une option pour la durée de validité. Le token émis peut expirer avec le temps, alors que la validité de Basic Auth et Key Auth est permanente, sauf si le serveur change le mot de passe ou la clé. De plus, la politique JWT peut être partagée entre plusieurs services, ce qui est bénéfique pour les scénarios de single sign-on (SSO).

OpenID Connect

OpenID Connect est une méthode d'authentification et d'autorisation basée sur le protocole OAuth2.0, offrant une solution d'application relativement complète. La politique OpenID Connect dans la passerelle API permet au service en amont d'obtenir les informations de l'utilisateur auprès du fournisseur d'identité (IdP), protégeant ainsi la sécurité de l'API. Les IdP courants sont Keycloak, Ory Hydra, Okta, Auth0, etc. Prenons l'exemple d'Apache APISIX, le flux de travail de la politique OpenID Connect dans la passerelle est le suivant :

1. Le client envoie une requête à la passerelle.
2. Après réception de la requête, la passerelle envoie une demande d'authentification à l'IdP.
3. L'utilisateur est redirigé vers la page fournie par l'IdP pour compléter l'authentification.
4. L'IdP redirige vers la passerelle avec le code d'authentification.
5. La passerelle demande un Access Token à l'IdP via le code pour obtenir les informations de l'utilisateur.
6. La passerelle peut inclure les informations de l'utilisateur lors de la redirection de la requête en amont.

Ce processus permet de séparer l'authentification et l'autorisation du métier, rendant l'architecture plus granulaire.

Pour plus de méthodes d'authentification et d'autorisation avec APISIX, veuillez consulter API Gateway Authentication.

Politique de sécurité

La politique de sécurité de la passerelle API agit comme un gardien pour garantir un accès sécurisé à l'API, permettant aux requêtes légales d'être redirigées par la passerelle et bloquant les requêtes illégales au niveau de la passerelle. Selon le projet de sécurité API d'OWASP, il existe de nombreuses menaces et attaques possibles sur les appelants d'API. L'utilisation de la politique de sécurité de la passerelle API permet de vérifier la sécurité de toutes les requêtes API, jouant un rôle essentiel dans la protection de l'API contre ces menaces de sécurité.

Voici quelques politiques de sécurité importantes pour les passerelles API :

Restrictions d'accès par IP

La politique de restriction par IP limite l'accès à l'API par certains clients en définissant des IP ou des CIDR dans une liste d'autorisation ou de refus pour empêcher l'accès malveillant à des données sensibles. Une configuration appropriée de cette politique améliorera considérablement la sécurité de l'API et permettra une meilleure gouvernance de la sécurité de l'API.

Blocage d'URI

La politique de blocage d'URI intercepte les requêtes API potentiellement dangereuses en définissant certaines règles d'URI. Par exemple, certaines attaques de sécurité détectent des vulnérabilités potentielles en reniflant le chemin de l'URI, puis attaquent. Apache APISIX fournit le plugin uri-blocker pour bloquer les requêtes API dangereuses. On peut également définir des expressions régulières via le plugin uri-blocker. La passerelle API bloquera la requête si celle-ci correspond à la règle. Par exemple, si nous configurons root.exe, admin, ce plugin peut bloquer les requêtes */root.exe et */admin pour protéger davantage la sécurité de l'API.

CORS

CORS (Cross-origin resource sharing) est la politique de sécurité du navigateur pour les requêtes interdomaines. Généralement, avant d'envoyer une requête xhr dans le navigateur, celui-ci vérifie si l'adresse de la requête et l'adresse actuelle sont dans la même origine. Les requêtes dans la même origine sont envoyées directement. Sinon, le navigateur envoie d'abord une requête préalable de type OPTION pour vérifier les paramètres CORS dans l'en-tête de réponse, comme les méthodes et les informations d'identification autorisées dans les requêtes interdomaines. Le navigateur décide ensuite d'envoyer ou non une requête formelle en fonction de ces informations. Pour plus de détails, veuillez consulter CORS.

Généralement, la réponse contenant les paramètres CORS est définie par le service backend. Mais s'il y a de nombreux services, il sera plus sûr et plus pratique de les traiter uniformément au niveau de la passerelle. La politique CORS peut définir différentes politiques de résolution interdomaine sur différentes API, et les services en amont n'ont plus besoin de gérer cette logique.

CSRF

CSRF est une attaque par falsification de requête interdomaine, qui amène les utilisateurs finaux à effectuer des actions involontaires sur un site web où ils sont déjà authentifiés. Cette attaque est généralement accompagnée d'ingénierie sociale (envoi d'un lien malveillant à la victime par e-mail). Lorsque l'utilisateur clique sur le lien, l'attaquant utilise l'identité authentifiée de la victime pour effectuer des actions malveillantes sur le site web. Du point de vue du site web, toute action est attendue car l'utilisateur est déjà connecté.

Généralement, le service backend du site web doit ajouter un middleware supplémentaire pour gérer cette logique, et les méthodes de prévention ont des normes spécifiques. L'utilisation de la politique CSRF peut empêcher cette attaque et effectuer le traitement de sécurité CSRF au niveau de la passerelle, simplifiant ainsi la complexité logique des services en amont.

Politique de traitement du trafic

La politique de traitement du trafic vise principalement à garantir que la charge en amont de la passerelle API pour la redirection du trafic reste dans une plage saine. En même temps, la requête est réécrite à la demande avant d'être redirigée ou renvoyée à l'appelant. Ce type de politique concerne principalement des fonctionnalités telles que la limitation de débit, le circuit breaker, la mise en cache et la réécriture.

Limitation de débit (Rate Limiting)

Dans le cas de ressources limitées, la capacité de service que l'API peut fournir est limitée. Si les appels dépassent cette limite, le service en amont peut planter et provoquer des réactions en chaîne. La limitation de débit peut éviter de tels cas et peut efficacement empêcher les API d'être attaquées par des DDOS (attaques par déni de service).

Nous pouvons configurer une fenêtre de temps et un nombre maximum de requêtes autorisées dans la politique de limitation de débit. La passerelle API rejettera les requêtes dépassant le nombre maximum autorisé et renverra un message d'erreur de limitation de débit. La requête ne sera pas autorisée tant que le nombre de requêtes sera inférieur à la limite ou que la fenêtre de temps suivante s'ouvrira.

La variable pour le comptage des requêtes peut être définie dans la requête ou comme un en-tête de requête spécifique, par exemple, pour définir la politique de limitation de débit correspondante en fonction de différentes IP pour une meilleure flexibilité.

Circuit Breaker

La politique de circuit breaker de l'API peut fournir une capacité de circuit breaker pour les services en amont. Lors de l'utilisation de cette politique, vous devez définir les codes d'état des services en amont sains et malsains pour que la passerelle puisse juger de l'état des services en amont. En outre, il est également nécessaire de définir le seuil de requêtes pour déclencher une rupture ou restaurer la santé. Lorsque le service en amont renvoie continuellement des codes d'état malsains à la passerelle, celle-ci interrompra le service en amont pendant un certain temps. Pendant cette période, la passerelle ne redirigera plus les requêtes vers le service en amont mais renverra directement une erreur. Cela peut empêcher les services en amont de subir un "avalanche" de requêtes continues en raison d'erreurs et protéger les services métier. Après cette période, la passerelle essaiera de rediriger à nouveau la requête vers le service en amont. Si celui-ci renvoie toujours un code d'état malsain, la passerelle continuera à interrompre pendant une durée plus longue (doublée). Jusqu'à ce que le service en amont renvoie un certain nombre de codes d'état sains, la passerelle considérera que le service en amont est de nouveau sain et continuera à rediriger le trafic vers le nœud en amont.

Dans cette politique, il est également nécessaire de définir le code d'état et les informations à renvoyer en cas de mauvaise santé. Lorsque le service en amont est malsain, la requête est renvoyée directement au niveau de la passerelle pour protéger la stabilité des services métier.

Répartition du trafic (Traffic Splitting)

La politique de répartition du trafic peut contrôler dynamiquement la redirection du trafic vers différents services en amont en proportion. Elle est particulièrement utile dans les mises en production canari et les déploiements bleu-vert.

La mise en production canari permet à seulement une partie des requêtes d'utiliser le nouveau service, tandis que l'autre partie reste dans l'ancien service. Si le nouveau service reste stable, vous pouvez augmenter la proportion et transférer progressivement toutes les requêtes vers le nouveau service jusqu'à ce que le ratio soit entièrement basculé pour terminer la mise à niveau.

Le déploiement bleu-vert est un autre mode de déploiement, qui publie une nouvelle version pendant la période de pointe sans interrompre le service. Les anciennes et nouvelles versions du service coexistent. Généralement, l'environnement de production (bleu) est copié dans un conteneur identique mais séparé (vert). Les nouvelles mises à jour sont publiées dans l'environnement vert, puis les deux environnements vert et bleu sont publiés en production. L'environnement vert peut ensuite être testé et réparé pendant que l'utilisateur accède toujours au système bleu. Les requêtes peuvent ensuite être redirigées vers l'environnement vert en utilisant une politique d'équilibrage de charge. L'environnement bleu peut ensuite être maintenu en veille comme option de reprise après sinistre ou pour la prochaine mise à jour.

APISIX prend en charge les deux modes de déploiement via le plugin traffic-split, rendant le déploiement métier plus pratique et fiable.

Réécriture de réponse (Response Rewrite)

Dans l'architecture moderne des microservices, il existe de nombreux protocoles différents entre les services et aucun format de données de réponse uniforme. Si cette logique de transcodage est implémentée séparément dans chaque service, il y aura un code logique redondant, ce qui est difficile à gérer. Certaines politiques de réécriture de réponse peuvent gérer la conversion de protocole, la réécriture du corps de la requête et d'autres logiques.

APISIX fournit un plugin Response Rewrite pour modifier les informations de corps ou d'en-tête renvoyées par les services en amont et prend en charge l'ajout ou la suppression d'en-têtes de réponse, la définition de règles pour modifier le corps de la réponse, etc. Il est utile dans des scénarios tels que la définition d'en-têtes de réponse CORS pour les requêtes interdomaines ou la définition de l'emplacement pour la redirection.

D'autre part, APISIX fournit proxy-rewrite pour la réécriture de requêtes. Le plugin peut également gérer le contenu de la requête proxy vers le service en amont. Vous pouvez réécrire l'URI de la requête, la méthode, l'en-tête de la requête, etc., ce qui facilite le traitement métier dans de nombreux scénarios.

Injection de fautes (Fault Injection)

L'injection de fautes est une méthode de test logiciel qui garantit le comportement correct d'un système en introduisant intentionnellement des erreurs. Généralement, les tests sont effectués avant le déploiement pour s'assurer qu'il n'y a pas de défaillances potentielles dans l'environnement de production. Dans certains scénarios de test de chaos, il est nécessaire d'injecter des erreurs dans le service pour vérifier sa fiabilité.

L'injection de fautes logicielles peut être classée en injection au moment de la compilation et injection au moment de l'exécution. L'injection au moment de la compilation fait référence à la modification de certains codes ou logiques lors de l'écriture du logiciel. L'injection au moment de l'exécution teste le comportement du logiciel en définissant des erreurs dans l'environnement d'exécution du logiciel. La politique d'injection de fautes peut simuler des fautes dans les requêtes réseau de l'application via l'injection au moment de l'exécution. En sélectionnant un ratio dans la politique, les requêtes dans ce ratio exécuteront la logique de faute, comme renvoyer avec un délai ou renvoyer directement le code d'erreur et le message d'erreur définis à l'appelant. De cette manière, l'adaptabilité du logiciel est augmentée, permettant aux développeurs de voir à l'avance certaines situations d'erreur possibles et de faire des modifications adaptatives aux problèmes avant la publication.

Conversion de protocole (Protocol Conversion)

La politique de conversion de protocole peut convertir entre certains protocoles standard, comme les requêtes HTTP courantes et gRPC. Apache APISIX fournit le plugin grpc-transcode qui peut transcoder et rediriger la requête HTTP vers des services de type gRPC. La réponse est renvoyée au client au format HTTP. Ainsi, le client peut se concentrer uniquement sur HTTP sans se soucier du type de service gRPC en amont.

Politique d'observabilité

L'observabilité fait référence à la capacité de mesurer l'état de fonctionnement du système à travers les données de sortie du système. Dans certains systèmes simples, comme le nombre de composants du système est relativement faible, le bug peut être trouvé en analysant l'état de chaque composant lorsqu'une erreur se produit. Cependant, dans un système distribué à grande échelle, le nombre de composants de microservices est énorme, et il est irréaliste de vérifier les composants un par un. À ce moment-là, le système doit être observable. L'observabilité fournit la visibilité d'un système étendu, et lorsqu'un problème survient, elle peut donner aux ingénieurs le contrôle nécessaire pour localiser le problème.

La collecte de données peut être implémentée dans les composants de l'application. La passerelle API étant l'entrée de tout le trafic, l'implémentation des fonctionnalités d'observabilité du système dans la passerelle API peut refléter l'utilisation de l'API du système. Une politique d'observabilité de la passerelle API peut aider toutes les équipes :

• Une équipe d'ingénieurs peut surveiller et résoudre les problèmes d'API.
• L'équipe produit peut comprendre l'utilisation de l'API pour découvrir la valeur métier derrière celle-ci.
• Les équipes de vente et de croissance peuvent surveiller l'utilisation de l'API, surveiller les opportunités métier et s'assurer que les API fournissent les bonnes données.

Les politiques d'observabilité sont généralement divisées en trois catégories selon le type de données de sortie : Tracing, Metrics et Logging.

Tracing (Suivi de lien)

Dans un système distribué à grande échelle, la relation entre les services est complexe. Le suivi de lien (Tracing) peut suivre le lien d'appel complet, l'analyse des dépendances entre les applications et les statistiques de requêtes dans les applications distribuées. Lorsqu'un problème survient dans le système, il peut aider les ingénieurs à déterminer la portée et l'emplacement de l'investigation.

La politique de suivi de lien peut intégrer d'autres systèmes de suivi de lien distribué dans la passerelle API pour collecter et enregistrer des informations. Par exemple, intégrer des services comme Zipkin et SkyWalking dans la passerelle API pour collecter des données et la communication interservices. Ainsi, cette politique permet aux ingénieurs de savoir quel journal consulter pour une session spécifique ou des appels d'API connexes et de vérifier la portée du dépannage.

Metrics (Métriques)

Les métriques font référence aux données d'observation d'un logiciel collectées pendant un intervalle de temps de l'opération du service. Ces données sont structurées par défaut, ce qui facilite la requête et la visualisation. On peut apprendre l'état de fonctionnement du système à travers l'analyse de ces données.

La politique de métriques peut intégrer des services comme Prometheus ou Datadog dans la passerelle API pour fournir des capacités de surveillance et d'alarme pour le système. Cette politique collecte des données pendant l'opération de la passerelle via diverses interfaces de la passerelle API et rapporte les données à Prometheus ou Datadog. En visualisant ces données, les développeurs peuvent voir l'état de fonctionnement de la passerelle, les informations statistiques des requêtes API et d'autres graphiques statistiques.

Logging (Journalisation)

Le journal est un enregistrement textuel des événements du système à un moment spécifique. Le journal est le premier endroit à consulter lorsqu'un problème survient dans le système. Les ingénieurs s'appuient sur le contenu du journal pour découvrir ce qui s'est passé dans le système et la solution correspondante. Le contenu du journal est généralement divisé en journal des requêtes API et journal de fonctionnement de la passerelle. Le journal des requêtes API enregistre tous les enregistrements de requêtes API pendant le fonctionnement de la passerelle API. Les ingénieurs peuvent apprendre les informations d'accès à l'API à travers ces enregistrements et découvrir et résoudre les requêtes anormales à temps. Le journal de fonctionnement de la passerelle contient les enregistrements de tous les événements survenus pendant le fonctionnement de la passerelle. Lorsque la passerelle API est anormale, elle peut être utilisée comme une base essentielle pour le dépannage.

La politique de journalisation peut stocker les journaux de la passerelle API sur le disque du serveur ou les pousser vers d'autres serveurs de journaux, comme un serveur de journaux HTTP, TCP, UDP, etc., ou d'autres systèmes de journaux comme Kafka, RocketMQ, Clickhouse.

Résumé

Cet article présente quatre politiques couramment utilisées dans les passerelles API : l'authentification et l'autorisation, la sécurité, le traitement du trafic et l'observabilité. La passerelle API reçoit le trafic de requêtes avant tous les services en amont, contrôle où et comment les requêtes sont redirigées, et rejette ou restreint directement les requêtes non sécurisées et non autorisées. Les politiques de la passerelle API peuvent configurer tous ces comportements.

Pour plus d'informations sur les passerelles API, veuillez consulter les blogs et API7.ai pour plus de support commercial.