cloud-path

CloudPath est une plateforme de contrôle IoT auto-hébergée pouvant être exécutée localement ou déployée sur le cloud. Son objectif est de fournir un plan de contrôle universel pour l'accès aux appareils, la consultation d'état et le contrôle à distance, plutôt que d'être un logiciel dédié à une carte de développement spécifique. Le projet est open-source sous licence MIT et se compose de trois parties : le service central cloudpath-server (binaire unique), la passerelle cloudpath-edge installée sur chaque ordinateur ou site, et l'outil en ligne de commande cloudpath pour la gestion du registre des plugins. Techniquement, le backend est écrit en Go, le frontend en React (intégré au serveur), et la base de données utilise SQLite en mode WAL, permettant une compilation croisée vers Linux ou arm64 sans CGO. Répartition de l'autorité Le service central est l'unique autorité pour l'état souhaité, les locataires et l'audit. Il gère le RBAC, les jetons, la limitation de débit, les périodes de rétention, le catalogue des plugins et le règlement des opérations. La passerelle est l'unique autorité pour l'état d'observation ; elle conserve un instantané du dernier état appliqué avec succès, supervise les appareils, gère les tentatives de reconnexion et tamponne les événements hors ligne. En cas de coupure réseau, elle continue de fonctionner et n'applique que l'instantané final lors de la reconnexion, sans rejouer les effets secondaires intermédiaires. L'identité d'un appareil est définie par le triplet locataire/passerelle/appareil. Les communications en temps réel passent par WebSocket, tandis que REST est utilisé pour les requêtes historiques et la gestion. Système de plugins Le projet distingue trois types de plugins : les Drivers, exécutés côté passerelle pour la découverte, la connexion, l'analyse de protocole et les actions des appareils ; les Applications, exécutées côté service central pour les objets métier, les règles et les API de domaine ; et les Connectors (en cours de développement) pour les notifications et sorties de données via MQTT ou Webhook. Le cœur du système ne contient pas de code pour du matériel spécifique ; tout nouvel appareil correspond à un plugin Driver. Des modèles de plugins Go, des exemples d'applications et des outils de test E2E sont fournis dans des dépôts séparés. Avant l'installation, le manifeste, la compatibilité et les sommes de contrôle des actifs sont vérifiés. Démarrage rapide Après l'installation de Go, Node, pnpm et optionnellement task, les commandes task setup et task build permettent de générer les binaires. Le serveur écoute par défaut sur 127.0.0.1:8080 et propose un point de terminaison /healthz. Un adaptateur démo intégré permet de tester la connexion et les opérations sans matériel. Pour des appareils série réels, il faut installer le Driver correspondant et configurer plugin_host dans edge.yaml. Une fois le compte administrateur créé, le service passe en mode authentifié pour toutes les interfaces, sauf pour les ressources statiques et la santé du système. Console d'administration L'interface permet d'accéder à la vue d'ensemble, à la liste et aux détails des appareils, aux journaux d'événements, aux applications, aux plugins, aux passerelles et aux paramètres. L'administrateur dispose de pages supplémentaires pour les membres, les permissions et les jetons d'accès. Le panneau de commande des appareils génère des boutons basés sur la liste blanche déclarée par l'adaptateur. Les états des opérations sont : pending, sent, ok, failed, timeout. Les événements et les opérations finales sont conservés par défaut pendant 30 jours. Conception de sécurité Le README définit trois niveaux d'exposition : L0 (local), L1 (réseau interne/proxy inverse) et L2 (internet public). Deux modes de credentials existent : les jetons de service partagés et le mode compte (cookies de session, rôles admin/operator/viewer et jetons de locataire préfixés par cp_). Les jetons sont stockés sous forme de SHA-256 avec un court préfixe. Les secrets sont manipulés via des handles (secret://name) et ne sont résolus qu'au niveau de la passerelle cible ; le serveur ne stocke ni ne transmet les secrets en clair. Le système inclut également des listes blanches d'opérations, des limites de longueur de paramètres, des protections contre le path traversal SPA et des en-têtes de sécurité. Déploiement et accès multi-passerelles Le déploiement public recommandé utilise systemd avec un compte non-root, des fichiers d'environnement sécurisés (0600) et nginx comme proxy inverse pour HTTPS et WSS. L'authentification est gérée nativement par CloudPath. Pour connecter plusieurs passerelles à un seul serveur, l'administrateur crée des jetons de locataire avec un scope edge. L'utilisateur configure ensuite le point de terminaison WSS, le jeton et l'edge_id localement. Les passerelles gèrent la reconnexion avec un backoff exponentiel et un tampon d'événements borné. L'isolation est garantie entre les locataires. Tests et publication La couverture inclut des tests unitaires Go, la détection de race conditions, le typage frontend et des tests de flux de plugins. La publication est déclenchée par des tags de version pour six plateformes, générant un fichier de checksums unique. Des scripts de vérification des liens Markdown et de la structure des workflows sont également intégrés. Limites actuelles Le README distingue les fonctionnalités actuelles des objectifs futurs. Ne sont pas encore implémentés : le runtime des Connectors et notifications, l'accès MQTT/Modbus, l'OTA à distance, l'agrégation temporelle, la gestion centralisée des clés, les quotas distribués et le multi-serveur. Les sessions de jetons de locataire sont limitées à REST. Le support multi-cartes via un seul driver externe n'est pas encore totalement validé. Le projet suit le principe de ne pas présenter comme acquis les capacités non encore réalisées.