Bien démarrer avec les API REST Ootbi

La plupart des gens gèrent leur(s) Ootbi via son interface web, et pour une bonne raison : c’est Simple et rapide. Mais chaque Ootbi dispose aussi d’une API REST complète, et elle reçoit bien moins d’attention que l’interface utilisateur.

Selon Geoff Burke, conseiller principal en technologie, c’est une occasion manquée. L’API ouvre la voie à l’automatisation, aux intégrations avec les outils que vous utilisez déjà, et constitue un moyen de gérer Ootbi à grande échelle que le clic au fil des écrans ne peut pas égaler. De nombreuses autres fonctionnalités peuvent être réalisées dans l’interface utilisateur, comme créer des utilisateurs, vérifier l’état de santé du cluster, consulter les événements ou lister les buckets ; vous pouvez aussi faire tout cela par programmation.

Dans ce guide, Geoff Burke expliquera ce qu’est l’API REST Ootbi et pourquoi elle compte. Ensuite, il montrera comment vous pouvez vous connecter à un client API gratuit et open source pour Ootbi et effectuer vos premiers appels API.

Le rôle des API REST dans les opérations informatiques d’aujourd’hui

Au-delà de l’interface web

L’interface web est conçue pour une personne qui gère un système. Cela fonctionne jusqu’à ce que la charge augmente. Supposons que vous deviez créer 15 comptes utilisateurs, vérifier chaque matin l’état des mises à jour sur chaque appliance, ou exécuter le même rapport chaque semaine pour un auditeur. L’interface utilisateur devient alors une série de clics répétitifs.

Une API REST permet à un autre programme de faire ce travail à votre place. Votre script ou application envoie une requête à Ootbi, qui renvoie des données structurées, puis vous décidez de la suite. Cela élimine la nécessité de cliquer et de copier des valeurs depuis les écrans, réduisant les erreurs de saisie manuelle.

Les appels ne doivent pas non plus provenir de l’appliance. Ils peuvent venir d’un ordinateur portable, d’un serveur de gestion central, ou de tout système de votre réseau capable d’atteindre le cluster Ootbi.

Raisons courantes pour lesquelles les clients utilisent des API

• Efficacité opérationnelle : Automatisez les tâches répétitives qui grignotent le temps des administrateurs.

• Test des fonctionnalités : Vérifiez les changements et les nouveaux workflows sur un cluster de laboratoire avant de les déployer en production.

• Intégration avec les outils existants : Injectez les données Ootbi dans les plateformes de supervision, de ticketing et de Sécurité que vous utilisez déjà.

• Reporting et conformité : Récupérez à la demande les listes d’utilisateurs, les clés d’accès et les données d’événements, dans un format cohérent.

• Orchestration multi-systèmes : Les grandes organisations et les fournisseurs de services construisent souvent une application interne unique qui agrège les API de chaque produit qu’ils exploitent, matériel et logiciel.

Cas d’usage concrets de l’API Ootbi

Automatiser les tâches d’administration à grande échelle

• Gestion des utilisateurs : L’API propose les mêmes options de création d’utilisateurs que l’interface utilisateur, y compris les mêmes rôles. La différence, c’est que vous pouvez créer des utilisateurs par programmation, par exemple depuis votre processus de gestion des identités, plutôt qu’un par un.

• Contrôles d’état : Les requêtes d’informations sur le cluster et les nœuds renvoient des données détaillées, y compris les services Ootbi exécutés sur le cluster et leurs versions.

• Validation de la configuration : Un listing des buckets affiche des paramètres tels que l’activation du versioning. Le versioning est activé par défaut, mais un contrôle planifié peut confirmer que personne ne l’a désactivé.

• Administration du cluster : Récupérez les paramètres du cluster, les informations de licence et le certificat du cluster sans exporter quoi que ce soit manuellement depuis l’interface utilisateur.

Un exemple se démarque : l’API peut renvoyer les mises à jour actuellement disponibles pour un cluster ou pour des nœuds individuels. Si votre organisation exploite un système central de suivi des mises à jour, vous pouvez y connecter Ootbi. Il indiquera sa version actuelle et les mises à jour disponibles aux côtés de tout le reste de votre environnement. C’est plus important que jamais : les attaquants transforment désormais des vulnérabilités nouvellement divulguées en exploits fonctionnels plus vite que jamais ; tout système non corrigé est donc une cible.

Intégrations de supervision et d’alerting

Le point de terminaison des événements de Ootbi renvoie chaque événement avec son ID, sa source, sa sévérité et ses détails, le tout sous forme de JSON structuré. Cela rend les données faciles à envoyer vers des plateformes telles que :

• Splunk ou un autre SIEM, pour la visibilité Sécurité

• PagerDuty, pour l’alerte sur les événements de sévérité élevée

• ServiceNow, pour créer des tickets automatiquement

• Grafana, pour les tableaux de bord

Ensemble, ils font de Ootbi un élément d’une vue unifiée de votre infrastructure, plutôt qu’une console séparée à consulter.

Reporting de conformité et d’audit

• Collecte des données d’audit : Récupérez les listes des utilisateurs d’administration et leurs rôles, les sessions actives et les clés d’accès, y compris la date de dernière émission de chaque clé.

• Génération de rapports de conformité : Exécutez les mêmes appels selon un planning et produisez des rapports cohérents sans captures d’écran ni exports manuels.

• Support des environnements réglementés : Lorsqu’un auditeur demande qui a accès à votre Stockage des sauvegardes et à quel niveau, vous pouvez répondre avec des données extraites directement du système.

La visibilité sur les clés d’accès compte même dans les petits environnements. Dans un labo très actif où beaucoup de personnes créent des clés, un seul appel API affiche chaque clé et sa date de création ; le nettoyage se fait donc sur des faits plutôt que sur des suppositions.

Gestion MSP et multi-tenant

Les fournisseurs de services gèrent de nombreux produits pour de nombreux clients. Une approche courante consiste à construire une application interne unique au-dessus de l’API de chaque éditeur. Depuis cette application, l’équipe peut créer des comptes, provisionner des buckets de stockage et collecter des informations sans se connecter séparément à chaque système.

• Gestion de plusieurs déploiements clients : Interrogez le Ootbi de chaque client depuis un outil central unique.

• Création de portails de gestion personnalisés : Créez des vues adaptées, par exemple un portail pour des administrateurs juniors qui n’expose que certaines fonctions.

• Réduction de Charges opérationnelles supplémentaires : Standardisez le provisioning et le reporting sur l’ensemble des déploiements.

Explorer l’API Ootbi avec Swagger

Accéder à Swagger

Chaque Ootbi inclut une documentation d’API intégrée, propulsée par Swagger, un outil qui présente une API sous forme de page web interactive. Il n’y a rien de caché. Toute personne disposant d’un Ootbi peut l’ouvrir en ajoutant /swagger/index.html à l’adresse du cluster :

https://<your-Ootbi-cluster-address>:8443/swagger/index.html

Page d’accueil Swagger

Swagger liste chaque point de terminaison disponible, regroupé par domaine, notamment utilisateurs, clusters, nœuds, buckets, clés d’accès, événements et mises à jour. Chacun est marqué avec sa méthode HTTP :

• GET récupère des informations, comme une liste d’utilisateurs.

• POST envoie des informations, comme les détails d’un nouvel utilisateur.

Pour chaque point de terminaison, Swagger affiche la requête attendue et la réponse renvoyée. Vous pouvez aussi cliquer sur Try it out pour exécuter une requête directement depuis le navigateur.

Swagger fournit également la définition complète de l’API sous forme d’un fichier JSON unique téléchargeable. Les développeurs peuvent y effectuer des recherches, l’importer dans d’autres outils, ou le donner à un assistant IA pour explorer ce qu’ils pourraient construire.

Exemple de lien JSON Swagger : https://192.168.0.172:8443/swagger/v1/swagger.json

Remplacez l’ID de cluster de l’exemple par l’adresse IP de votre propre cluster.

 

Défis des tests d’API via navigateur

Swagger est excellent pour parcourir, mais moins pratique pour le travail réel :

• Friction d’authentification : Avant d’exécuter une requête, vous appelez le point de terminaison de connexion avec un nom d’utilisateur et un mot de passe, copiez le jeton bearer renvoyé, puis le collez dans la boîte de dialogue Autoriser de Swagger.

• Limites de gestion de session : Pour des raisons de Sécurité, les jetons Ootbi ont une durée de vie courte. Ils expirent rapidement, et vous devez répéter le processus, souvent au milieu de ce que vous faites.

• Absence de workflows réutilisables : Swagger n’enregistre ni vos valeurs ni vos requêtes. Chaque session repart de zéro.

C’est pourquoi nous utilisons un client API Dédié.

Travailler avec l’API Ootbi dans un client API

Vous pouvez utiliser n’importe quel client API pour travailler avec l’API Ootbi. Les étapes ci-dessous sont des instructions générales pour connecter un client API à Ootbi. Veuillez noter que les noms de menus et les options peuvent varier selon le client ; consultez donc la documentation de votre client pour plus de détails.

Ce qu’un client API vous apporte lors des tests de Ootbi

• Paramètres d’authentification enregistrés : Configurez la connexion une seule fois et réutilisez-la pour chaque requête.

• Renouvellement automatique des jetons : Un court script peut récupérer un nouveau jeton et le renouveler automatiquement, afin que les durées de vie courtes des jetons n’interrompent pas votre travail.

• Collections et environnements : Importez l’intégralité de l’API Ootbi sous forme de collection consultable et utilisez des environnements pour basculer entre les clusters de laboratoire et de production.

• Tests plus rapides : Modifiez une valeur, cliquez sur envoyer et observez le résultat. Plus besoin de copier des jetons d’un onglet à l’autre.

Clients API courants

Voici trois clients API largement utilisés, listés par ordre alphabétique. Ce sont des exemples, pas des recommandations. Choisissez celui qui correspond le mieux aux besoins de votre équipe et aux politiques Sécurité.

Bruno

Bruno est un client API léger, orienté local, pour créer et tester des requêtes API. Il est gratuit et open source. Les collections sont enregistrées sous forme de fichiers texte brut sur votre machine ; vous pouvez donc placer les requêtes sous contrôle de version dans Git et les partager via vos dépôts existants. Bruno importe des fichiers OpenAPI (Swagger) et prend en charge les environnements, les variables secrètes et le scripting.

Insomnia

Développé par Kong, Insomnia est un client API multiplateforme connu pour son interface claire et intuitive. Comme Bruno, il est gratuit et open source. Il gère de nombreux protocoles, notamment REST, GraphQL, gRPC et WebSockets, et vous pouvez stocker les projets localement, les synchroniser avec Git ou les stocker dans le cloud. Insomnia importe également des fichiers OpenAPI (Swagger) et ajoute des plugins pour des workflows personnalisés.

Postman

En tant que l’une des plateformes API les plus largement adoptées, Postman offre aux équipes un emplacement unique pour concevoir, tester, documenter et superviser des API. Il est gratuit à télécharger pour macOS, Windows et Linux, et il fonctionne aussi dans un navigateur web. Postman prend en charge les imports OpenAPI (Swagger), les environnements, les scripts de pré-requête et de test, ainsi que l’exécution automatisée de collections. Ses espaces de travail partagés facilitent la collaboration en équipe.

Connecter votre client API à Ootbi

Étape 1 : Installer un client API

Chaque client aura son propre processus d’authentification, qui doit pouvoir importer le fichier JSON Swagger.

Étape 2 : Tester la connectivité

Exécutez une requête Simple, par exemple celle qui renvoie les sessions actives. Un code d’état 200 signifie que Ootbi accepte votre jeton et que la connexion fonctionne. La réponse liste les sessions actuelles sur le cluster, y compris la vôtre.

Exécuter vos premiers appels API Ootbi

Exemple 1 : Récupérer les informations du cluster

Envoyez la requête Obtenir des informations générales sur les clusters. La réponse est détaillée : en plus des détails sur le cluster et les nœuds, elle liste les services Ootbi en cours d’exécution sur le cluster et leurs versions, des informations que vous ne trouverez pas regroupées au même endroit dans l’interface utilisateur.

Exemple 2 : Vérifier les mises à jour disponibles

Envoyez la requête mises à jour actuellement disponibles en utilisant l’ID de votre cluster. La réponse affiche votre version actuelle et toute version disponible.

En pratique, un outil central de supervision des mises à jour exécuterait cet appel selon un planning, enregistrerait la version actuelle et signalerait lorsqu’une mise à jour devient disponible. Il existe aussi une version de cette requête par nœud, ce qui aide à repérer un nœud en retard dans un cluster multi-nœuds.

Exemple 3 : Extraire les utilisateurs et les données d’événements

Pour un exemple axé conformité, essayez deux requêtes :

• Renvoie la liste des utilisateurs de gestion : Renvoie chaque utilisateur de gestion avec son rôle et son niveau d’accès. Créez un nouvel utilisateur en lecture seule (rôle Monitoring) dans l’interface utilisateur, relancez la requête, et le nouvel utilisateur apparaît immédiatement : un moyen rapide de vérifier que l’API et l’interface utilisateur affichent les mêmes données.

• Événements : Renvoie les événements avec leur ID, leur source, leur sévérité et leurs détails. Il s’agit des mêmes informations que celles obtenues via syslog, mais sous forme de JSON structuré ne nécessitant aucun parsing. C’est prêt à être ingéré dans un SIEM ou un outil de reporting.

Aller plus loin : créer des intégrations

Exporter les données Ootbi vers un SIEM

Votre équipe Sécurité veut des événements d’infrastructure Sauvegarde aux côtés de tout le reste. Un workflow Simple :

1. Un script sur votre serveur collecteur authentifie Ootbi et demande les événements selon un planning.
2. Il ne conserve que les nouveaux événements depuis la dernière exécution.
3. Il les transfère vers votre SIEM, où ils peuvent être corrélés, recherchés et utilisés pour déclencher des alertes.

Créer des rapports automatisés

La même approche alimente le reporting planifié. Récupérez chaque semaine les utilisateurs, les clés d’accès, les buckets (y compris l’état du versioning) et les informations de licence, puis transformez les résultats en un rapport cohérent ou un tableau de bord que votre équipe consulte chaque jour.

Intégrer aux workflows IT existants

• Systèmes de ticketing : Ouvrez automatiquement un ticket lorsqu’un événement de sévérité élevée apparaît, ou lorsqu’une mise à jour devient disponible.

• Plateformes de supervision : Ajoutez les données de santé et de capacité de Ootbi aux tableaux de bord que votre équipe d’exploitation utilise déjà.

• Outils internes : Intégrez Ootbi à votre portail de provisioning, par exemple pour créer des utilisateurs ou des buckets dans le cadre de l’onboarding d’une nouvelle équipe ou d’un nouveau client.

Avec les assistants de codage IA, créer ces petites intégrations est plus simple que jamais, même si vous ne vous considérez pas comme développeur.

Conclusion

L’API REST Ootbi étend Ootbi bien au-delà de l’interface web. Elle est intégrée à chaque appliance, documentée via Swagger et accessible à toute personne possédant un Ootbi. Veillez à choisir un client API facile à explorer, à tester et, à terme, à automatiser pour des workflows pilotés par API.

Que vous soyez administrateur IT, développeur, MSP ou équipe Sécurité, l’API Ootbi peut vous aider à rationaliser les opérations, améliorer la visibilité et intégrer votre infrastructure Sauvegarde à vos processus d’entreprise existants. Ouvrez Swagger sur votre cluster et voyez ce que vous pouvez construire.