Environnement PROVISION

L’environnement PROVISION est un composant essentiel de l’offre Reemo Containers. Il héberge et gère les conteneurs des utilisateurs, tout en assurant la communication avec l’environnement INFRA via des échanges sécurisés en HTTPS.

Architecture

L’environnement PROVISION repose sur deux briques principales :

  • NGINX : point d’entrée HTTP(S) du serveur de provisionnement. Il gère les connexions entrantes et les redirige vers l’API interne.

  • API Docker : interface de communication directe avec le moteur Docker, accessible uniquement via un Unix Socket pour garantir la sécurité et limiter les accès externes.

La communication entre les composants internes (NGINX et API Docker) ne transite jamais sur le réseau mais reste locale via une Socket Unix, ce qui réduit la surface d’attaque.

Relations avec l’environnement INFRA

  • Le serveur INFRA communique avec PROVISION uniquement via HTTPS.

  • Toutes les commandes de création, gestion et suppression de conteneurs sont transmises depuis l’API du serveur INFRA vers l’API Docker du serveur PROVISION.

  • Cette séparation garantit que la gestion centralisée reste dans l’INFRA, tandis que l’exécution des conteneurs est déportée sur les serveurs PROVISION.

Déploiement

Plusieurs architectures sont possibles en mixant la notion de manager et worker dans l’univers Docker Swarm

Déploiement à 1 niveau

../../_static/images/infra/provision_simple.png

Déploiement à 2 niveaux

Une architecture à 2 niveaux en séparant les managers et les workers est à privilégier dans un environnement demandant un haut niveau de sécurité

../../_static/images/infra/provision_manager.png

Isolation

Plusieurs niveaux d’isolation sont disponibles en fonction des besoins et des niveaux de sécurité demandés

Avoir plusieurs environnements de Provision pour gérer par client ou par type de conteneur

../../_static/images/infra/provision_isolationcluster.png

Déploiement d’un conteneur

Le déploiement d’un conteneur dans l’environnement Reemo Containers suit un enchaînement précis de requêtes et de validations entre l’environnement Infra et l’environnement Provision.

Cette chaîne garantit la sécurité, la traçabilité et la disponibilité des conteneurs pour l’utilisateur final.

../../_static/images/infra/provision_docker.png

Processus complet de déploiement d’un conteneur RBI entre l’utilisateur, le serveur Infra et le serveur Provision.

Étapes du processus

  1. Demande d’un conteneur L’utilisateur initie une requête via le portail Reemo, depuis un navigateur. Cette demande correspond à la demande d’ouverture d’un conteneur.

  2. Validation de l’API Le service API (au sein de l’environnement Infra) reçoit la requête et la valide. Les informations nécessaires sont enregistrées dans la base de données.

  3. Transmission au serveur Provision L’API envoie une demande de création de conteneur au serveur Provision via une communication sécurisée en HTTPS.

  4. Redirection par NGINX Le serveur Provision reçoit la requête et la relaie à l’API Docker via son frontal NGINX.

  5. Création du conteneur via Unix Socket L’API Docker, accessible uniquement par Unix Socket, transmet la demande au moteur Docker (Swarm ou autre orchestrateur) pour lancer le conteneur demandé.

  6. Enregistrement dans l’Infra Une fois le conteneur déployé, le Docker s’enregistre auprès du serveur Infra afin de rendre le conteneur disponible et visible pour l’utilisateur.

  7. Connexion établie La communication entre l’utilisateur et son conteneur est alors mise en place, par défaut via WebRTC en DTLS, assurant un flux sécurisé et performant.

Résumé du flux

  • Infra (Traefik, API, Signal, Apicron) gère la validation, la planification et l’enregistrement.

  • Provision (NGINX, API Docker) orchestre la création effective du conteneur.

  • La communication est cloisonnée et sécurisée : HTTPS entre serveurs et Unix Socket en interne.

Etablissement de la connexion à un conteneur

L’établissement d’une connexion entre un utilisateur et un conteneur déployé dans Reemo Containers suit plusieurs étapes clés. Le processus repose sur les protocoles WebRTC, WSS et DTLS, garantissant un échange sécurisé et performant.

../../_static/images/infra/connexion_reemo.png

Établissement d’une connexion WebRTC sécurisée entre un utilisateur et un conteneur via l’infrastructure Reemo.

Étapes du processus

  1. Demande de connexion du WebClient L’utilisateur (via son navigateur) initie une requête de connexion à un conteneur distant.

  2. Vérification par l’API Le service API vérifie les droits d’accès de la demande. Si la demande est valide, il génère un token et retourne l’adresse du serveur Signal qui gère la connexion avec le conteneur cible.

  3. Connexion au serveur Signal Le WebClient contacte le serveur Signal via WSS et lui transmet le token d’authentification.

  4. Autorisation par Signal Le serveur Signal valide le token et autorise ou refuse l’échange d’informations nécessaires à l’établissement de la connexion WebRTC. En cas d’acceptation, la connexion avec Signal est maintenue pour les échanges de contrôle.

  5. Génération des SDP (Session Description Protocol) Le WebClient et l’Agent Reemo (dans le conteneur) génèrent chacun un SDP, qui contient : - la description des canaux de communication à ouvrir, - le fingerprint de la clé de chiffrement pour la connexion.

  6. Échange des SDP Les deux SDP sont échangés via le serveur Signal en WSS.

  7. Établissement des candidats ICE Le WebClient et ReemoService établissent la liste de leurs candidats ICE (adresses réseau potentielles) en s’appuyant sur le serveur STUN.

  8. Échange des candidats ICE Les candidats ICE sont échangés via le serveur Signal, toujours en WSS.

  9. Handshake DTLS et connexion directe Une fois les informations échangées, un handshake DTLS est effectué. Cela permet d’établir une connexion P2P chiffrée et directe entre l’utilisateur et son conteneur.

Résumé du flux

  • Infra (API, Signal, Portal) : validation, génération de tokens, orchestration des échanges.

  • Provision (NGINX, API Docker, ReemoService) : héberge et exécute le conteneur.

  • STUN/ICE : facilite l’établissement de la communication directe malgré les NAT/firewalls.

  • DTLS : assure le chiffrement de bout en bout des flux.