PROVISION Environment

The PROVISION environment is a key component of the Reemo Containers offering. It hosts and manages user containers while ensuring communication with the INFRA environment through secure HTTPS exchanges.

Architecture

The PROVISION environment relies on two main components:

  • NGINX: the HTTP(S) entry point of the provisioning server. It handles incoming connections and routes them to the internal API.

  • Docker API: direct communication interface with the Docker engine, accessible only via a Unix Socket to ensure security and restrict external access.

Communication between internal components (NGINX and Docker API) never transits over the network but remains local through a Unix Socket, reducing the attack surface.

Relations with the INFRA Environment

  • The INFRA server communicates with PROVISION only via HTTPS.

  • All container creation, management, and deletion commands are sent from the INFRA API to the Docker API on the PROVISION server.

  • This separation ensures centralized management remains in INFRA, while container execution is delegated to PROVISION servers.

Deployment

Multiple architectures are possible by mixing manager and worker roles in the Docker Swarm ecosystem.

Single-level Deployment

Two-level Deployment

A two-level architecture, separating managers and workers, is recommended in environments requiring a high level of security.

Isolation

Different isolation levels are available depending on requirements and security needs.

Create multiple Provision environments to manage by client or container type.

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

Container Deployment

Deploying a container in the Reemo Containers environment follows a specific sequence of requests and validations between the Infra and Provision environments.

This chain ensures the security, traceability, and availability of containers for the end user.

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

Full RBI container deployment process between the user, Infra server, and Provision server.

Process Steps

  1. Container Request The user initiates a request via the Reemo portal from a browser. This corresponds to a request to open a container.

  2. API Validation The API service (within the Infra environment) receives the request and validates it. The necessary information is stored in the database.

  3. Forwarding to the Provision Server The API sends a container creation request to the Provision server via secure HTTPS communication.

  4. Redirection by NGINX The Provision server receives the request and forwards it to the Docker API via its NGINX frontend.

  5. Container Creation via Unix Socket The Docker API, accessible only via Unix Socket, sends the request to the Docker engine (Swarm or another orchestrator) to launch the requested container.

  6. Registration in Infra Once the container is deployed, Docker registers it with the Infra server to make the container available and visible to the user.

  7. Connection Established Communication between the user and their container is established, by default via WebRTC over DTLS, ensuring a secure and efficient flow.

Flow Summary

  • Infra (Traefik, API, Signal, Apicron) handles validation, scheduling, and registration.

  • Provision (NGINX, Docker API) orchestrates actual container creation.

  • Communication is segmented and secured: HTTPS between servers and Unix Socket internally.

Establishing a Connection to a Container

Establishing a connection between a user and a deployed container in Reemo Containers follows several key steps. The process relies on WebRTC, WSS, and DTLS, ensuring secure and efficient exchanges.

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

Establishing a secure WebRTC connection between a user and a container via the Reemo infrastructure.

Process Steps

  1. WebClient Connection Request The user (via their browser) initiates a connection request to a remote container.

  2. API Verification The API service verifies the access rights of the request. If valid, it generates a token and returns the address of the Signal server managing the connection with the target container.

  3. Connection to the Signal Server The WebClient contacts the Signal server via WSS and transmits the authentication token.

  4. Authorization by Signal The Signal server validates the token and either authorizes or rejects the exchange of information necessary to establish the WebRTC connection. If accepted, the connection with Signal is maintained for control exchanges.

  5. SDP (Session Description Protocol) Generation Both the WebClient and the Reemo Agent (in the container) generate an SDP, which contains: - the description of communication channels to be opened, - the encryption key fingerprint for the connection.

  6. SDP Exchange The two SDPs are exchanged via the Signal server over WSS.

  7. ICE Candidate Establishment The WebClient and ReemoService establish their list of ICE candidates (potential network addresses) using the STUN server.

  8. ICE Candidate Exchange ICE candidates are exchanged through the Signal server, still over WSS.

  9. DTLS Handshake and Direct Connection Once the information is exchanged, a DTLS handshake is performed. This establishes a direct, encrypted P2P connection between the user and their container.

Flow Summary

  • Infra (API, Signal, Portal): validation, token generation, orchestration of exchanges.

  • Provision (NGINX, Docker API, ReemoService): hosts and runs the container.

  • STUN/ICE: facilitates direct communication despite NAT/firewalls.

  • DTLS: ensures end-to-end encrypted communication.