Regarder les demandes passer : reconstruire une spécification d’API avec APIClarity

Reconstruire une spécification OpenAPI par l’observation

Les API sont omniprésentes dans les architectures de microservices modernes. Ils facilitent la consommation de données provenant d’applications externes et réduisent la quantité de code que les développeurs doivent écrire. Le résultat général est une livraison plus facile de produits logiciels utiles. Cependant, la prévalence des API signifie qu’elles représentent une grande surface d’attaque. En fait, Gartner prédit que d’ici 2022, les attaques d’API seront le vecteur d’attaque le plus courant pour les applications Web d’entreprise. De même, un rapport d’IBM a révélé que les deux tiers des violations de données pouvaient être attribuées à des API mal configurées.

De toute évidence, les entreprises doivent adopter une approche proactive pour s’assurer que leur utilisation des API est sécurisée. Malheureusement, avec la complexité des applications modernes, les dépendances de code tiers et le manque de documentation, L’observabilité des API est un énorme défi. Souvent, les entreprises n’ont tout simplement aucune spécification API pour leurs applications de production. En conséquence, les erreurs de configuration liées à la sécurité ne sont pas détectées et les applications utilisent une variété d’« API zombies » obsolètes et d’« API fantômes » non documentées en production.

La première étape fondamentale pour résoudre ce problème consiste à créer une spécification d’API et à l’utiliser pour auditer et documenter les API utilisées par vos applications. Idéalement, nous créerions une spécification d’API simplement en observant le trafic d’API dans des applications du monde réel. Dans le passé, il n’existait aucun outil simple, évolutif et open source capable de le faire. Maintenant, nous avons APIClarity – un outil de visibilité du trafic API open source pour les clusters Kubernetes (K8s). Il est spécialement conçu pour combler l’écart et permettre la reconstruction de l’API par l’observation.

Dans cet article, nous allons voir ce qu’est la reconstruction d’API et comment APIClarity résout le problème d’observabilité de l’API. Ensuite, nous passerons en revue un exemple pratique d’utilisation d’APIClarity avec une application basée sur des microservices s’exécutant sur des K8.

L’importance de la reconstruction de l’API

En termes simples, la reconstruction d’API est la construction d’une spécification d’API simplement en observant le trafic vers et depuis cette API. Bien faite, la reconstruction d’API vous donne une visibilité sur les API utilisées par vos microservices et vous permet d’évaluer les risques de sécurité de vos API. Une fois la spécification créée, le même outil peut comparer le trafic d’exécution à la spécification pour détecter les écarts.

Les composants clés d’une spécification d’API incluent :

• Détection de paramètres (chemins, paramètres d’en-tête, paramètres de requête, paramètres de corps de requête et cookies)
• Références d’objets
• Transfert de fichier
• Définitions de sécurité

Idéalement, un outil de reconstruction d’API doit quantifier ces composants dans un format conforme à la spécification OpenAPI (OAS) sans introduire de surcharge ou de complexité inutiles pour une application. Avant APIClarity, il y avait plusieurs outils qui partiellement cas d’utilisation de reconstruction d’API, mais il n’y avait pas de solutions open source complètes. Certains de ces autres outils pour la visibilité de l’API incluent :

• Optique —un outil extensible, indépendant du langage et open source. Il est utile pour documenter, réviser et approuver l’API avant le déploiement.
• SwaggerHub —un outil populaire pour convertir le trafic API en OAS.
• Requin d’API CloudVector —peut surveiller les environnements multiservices et générer une spécification OAS à partir du trafic d’exécution.
• Visionner —un outil robuste de visibilité et de documentation des API pour les environnements multiservices.

Optic n’a pas été conçu pour surveiller les environnements multiservices et SwaggerHub ne s’intègre pas aux environnements d’exécution. Ni API Shark ni Imvision ne sont open source. Aucun des outils ci-dessus ne répondait pleinement aux besoins de reconstruction de l’API.

Comment APIClarity résout le défi de la reconstruction et de la visibilité de l’API

APIClarity comble les lacunes laissées par d’autres outils et fournit une solution de visibilité et de reconstruction d’API multiservices robuste, open source et évolutive. Il s’intègre facilement dans les environnements existants à l’aide d’un framework de service mesh. Avec APIClarity, les développeurs peuvent importer une spécification d’API ou en reconstruire une en fonction de l’observation. Les développeurs peuvent également surveiller tout le trafic des API en temps réel sans qu’aucun changement de code ou de charge de travail ne soit nécessaire.

Alors, comment ça marche?

Source de l’image

• APIClarity est déployé dans les clusters K8 existants
• Le trafic de l’API est mis en miroir des pods du cluster vers le moteur de spécification OpenAPI d’APIClarity
• Le moteur de spécifications surveille le trafic interne et externe et enregistre les événements de l’API
• APIClarity apprend les spécifications basées sur le trafic API et crée une spécification API
• Les utilisateurs révisent, modifient et approuvent les spécifications
• APIClarity alerte les utilisateurs des problèmes de sécurité ou s’il existe un écart entre une API observée et la spécification API approuvée

APIClarity en action : une procédure pas à pas

Maintenant que nous savons ce qu’est APIClarity, plongeons-nous dans notre tutoriel pour le voir en action avec un cluster K8s et une application basée sur des microservices. Ici, nous allons :

1. Déployez l’application Sock Shop dans notre cluster K8s. Bien que nous utilisions Sock Shop comme exemple d’application, vous pouvez déployer votre propre application sur votre cluster et continuer à suivre.
2. Déployez APIClarity dans notre cluster K8s et configurez la surveillance
3. Observez le trafic API sur le tableau de bord APIClarity
4. Examinez et créez une spécification d’API et affichez la spécification OpenAPI générée au format Swagger.
5. Identifiez les écarts par rapport à une spécification d’API ainsi que l’utilisation d’API fantômes et zombies.
6. Afficher et filtrer les événements API

Conditions préalables

Pour suivre, vous aurez besoin de :

• Cluster Kubernetes avec une valeur par défaut StorageClass défini
• Istio 1.10 ou supérieur, installé sur le cluster

Votre cluster K8s peut être déployé sur n’importe quelle plate-forme que vous préférez, y compris minikube. Bien qu’APIclarity prenne en charge plusieurs intégrations pour le proxy du trafic API, vous devez télécharger et installer Istio.

Déployez l’application Sock Shop dans votre cluster K8s

Nous utiliserons la populaire application de microservices Sock Shop comme application de test. Avec 14 microservices différents et un front-end interactif, c’est un excellent moyen de tester le trafic API dans un cluster K8s.

1) Créer le sock-shop espace de noms.

kubectl create namespace sock-shop

2) Activer l’injection Istio pour le sock-shop espace de noms.

kubectl label namespaces sock-shop istio-injection=enabled

3) Déployez l’application de démonstration Sock Shop dans votre cluster.

kubectl apply -f https://raw.githubusercontent.com/microservices-demo/microservices-demo/master/deploy/kubernetes/complete-demo.yaml

4) Obtenez le NodePort pour le front-end service.

kubectl describe svc front-end -n sock-shop | grep NodePort:

La sortie devrait ressembler à ceci :

NodePort:                 <unset>  30001/TCP

5) Connectez-vous à http://<node_IP>:<NodePort> dans votre navigateur. En utilisant notre exemple ci-dessus, si l’IP de notre nœud est 192.168.49.2, accédez à http://192.168.49.2:30001. Si vous ne connaissez pas l’IP de votre nœud, vous pouvez vérifier avec kubectl get nodes -o yaml ou minikube ip. Si tout fonctionne, l’application de démonstration Sock Shop devrait se charger.

Déployez APIClarity dans notre cluster K8s et configurez la surveillance

Tout d’abord, nous devons déployer APIClarity dans notre cluster.

1) Nous allons commencer par cloner le référentiel GitHub dans notre répertoire personnel :

cd ~
git clone https://github.com/apiclarity/apiclarity

2) Ensuite, accédez au apiclarity annuaire.

3) Utiliser kubectl pour déployer APIClarity. En utilisant le apiclarity.yaml par défaut, l’espace de noms sera apiclarity.

kubectl apply -f deployment/apiclarity.yaml

4) Confirmez que les pods sont en cours d’exécution.

kubectl get pods -n apiclarity

La sortie devrait ressembler à ceci :

NAME                          READY   STATUS    RESTARTS   AGE
apiclarity-679949b687-x25pb   1/1     Running   0          16m
apiclarity-postgresql-0       1/1     Running   0          16m

5) Initialiser et mettre à jour le wasm-filters sous-module :

git submodule init wasm-filters
git submodule update wasm-filters

6) Naviguez jusqu’au wasm-filters dossier:

7) Exécutez le wasm ./deploy.sh script afin que le filtre Envoy Wasm puisse capturer le trafic de notre boutique de chaussettes. Le script accepte plusieurs espaces de noms comme paramètres d’entrée, par exemple ./deploy.sh <namespace_one> <namespace_two> <namespace_three>, mais pour cette démo, il suffit de spécifier le sock-shop espace de noms.

8) Configurez la redirection de port pour APIClarity.

kubectl port-forward -n apiclarity svc/apiclarity 9999:8080

9) Utilisez un navigateur Web pour vous connecter à l’interface graphique APIClarity à http://localhost:9999.

Observez le trafic API sur le tableau de bord APIClarity

Maintenant, il est temps de générer du trafic. Commencez par cliquer sur les différents boutons et menus de l’application Sock Shop.

• Conseil de pro : plus il y a de trafic API, mieux c’est ! Plus de trafic = plus d’observations = visibilité plus profonde. Pour cette partie de notre démo, nous avons juste besoin d’un peu de trafic, mais gardez ce principe à l’esprit pour la production.

Après avoir généré du trafic API dans Sock Shop, retournez au tableau de bord APIClarity. Vous remarquerez qu’APIclarity a enregistré tous les différents appels d’API qui ont été effectués. Dans notre exemple ci-dessous, nous pouvons voir 17 appels au catalogue point de terminaison, huit appels à carts, et trois appels à user. Nous pouvons également voir comment APIClarity commence à représenter graphiquement l’utilisation de l’API. Ces graphiques deviendront encore plus intéressants et utiles une fois que nous aurons généré plus de trafic et créé nos spécifications d’API.

Examiner et créer une spécification d’API et afficher les documents dans Swagger

Créons maintenant une spécification d’API basée sur la quantité relativement faible de trafic que nous avons.

1) Cliquez sur l’une des « API les plus utilisées ». je vais utiliser catalogue.

2) Cliquez sur l’onglet « Reconstruit » puis cliquez sur « Examiner ».

3) Ici, nous pouvons examiner les chemins d’API, ajouter des paramètres et fusionner des entrées. je vais ajouter un example_param et examiner et approuver les chemins. N’hésitez pas à expérimenter vos choix ici.

4) Maintenant, nous avons une spécification API OAS. Nous pouvons afficher les documents de l’API dans Swagger directement à partir de l’interface graphique APIClarity.

Identifier les écarts par rapport à une spécification API

Maintenant que nous avons une spécification d’API comme référence, APIClarity peut signaler les écarts par rapport à la spécification pour aider à détecter les problèmes de sécurité et les API fantômes. Pour voir comment cela fonctionne, revenez à l’interface graphique de Sock Shop et expérimentez encore. Cliquez sur certaines fonctionnalités ou filtres que vous n’avez pas utilisés la dernière fois. Si vous avez créé une commande, supprimez-la. La clé ici est d’effectuer certaines actions qui ne sont pas dans les spécifications. Ceux-ci seront identifiés comme « diffs ».

Par exemple, ici, j’ai passé plusieurs appels au catalogue point de terminaison qui ne correspond pas à mes spécifications :

Nous pouvons explorer en cliquant sur une différence spécifique et voir exactement ce qui est différent de la spécification. Ici, nous pouvons voir que l’écart a été détecté car mon appel API manquait de certains paramètres.

C’est un exemple d’appel d’API documenté avec des paramètres différents de ceux de la spécification. Mais que se passe-t-il si l’appel d’API n’est pas du tout documenté dans la spécification ? Dans ce cas, APIClarity le marquera comme une API fantôme.

C’est exactement ce qui s’est passé pour cet appel d’API au carts chemin. Au moment où nous avons créé la spécification, nous n’avons observé qu’un GET et un POST, c’est donc ce qui a été documenté. Par conséquent, un appel DELETE était en dehors de la spécification et signalé comme un API fantôme.

Comme vous pouvez vous y attendre, il s’agit d’un appel d’API légitime que j’aurais dû documenter. Ce scénario nous fournit un exemple pratique des raisons pour lesquelles il est utile de laisser APIClarity capturer une grande quantité de trafic avant de créer votre spécification d’API.

Afficher et filtrer les événements API

Nous pouvons également afficher et filtrer les événements API avec APIClarity.

Pour afficher les événements, cliquez sur l’icône des événements :

Ici, vous verrez une liste détaillée de tous les événements API…