Choix technologiques

L’architecture de hepto, simple en apparence, repose sur des choix de conception non triviaux, dont les principaux sont explicités à suivre.

Les ressources mises en commun dans le cadre d’un cluster sont :

  • la puissance CPU ;
  • la capacité mémoire ;
  • la capacité de stockage ;
  • la connectivité réseau ;
  • l’espace d’adressage et de nommage.

Socle réseau et socle orchestration

Ces ressources sont principalement divisées entre les ressources réseau, à savoir la connectivité et la capacité de routage associée d’une part ; et les ressources d’orchestration – le reste – d’autre part.

Lors de la conception d’un cluster distribué géographiquement, il apparaît que la connectivité réseau est essentielle et associée à des propriétés encore peu systématisées dans le déploiement de clusters traditionnels, à commencer par la sécurité des communications internes au cluster.

Aussi, il apparaît que les deux types de ressources doivent être gérés par deux technologies distinctes bien que complémentaires. En résultent deux approches envisageables :

  • soit disposer d’une connectivité réseau sécurisée entre les noeuds du cluster, sur la base de laquelle l’orchestration est construite ;
  • soit construire une orchestration indépendamment des propriétés de sécurité réseau et déployer en sus les outils pour sécuriser les communications au sein des applications.

La première approche est assez traditionnelle, orientée VPN (réseau privé virtuel, construit par dessus l’infrastructure réseau existante), tandis que la seconde s’inscrit dans la logique contemporaine du zero trust, ne postulant ni de la confiance dans l’infrastructure sous-jacente à l’orchestration, ni dans la confiance des applications entre elles au sein du cluster.

Les limites du zero-trust

L’approche zero-trust, non seulement par sa modernité, mais également par sa vision très conservatrice de la sécurité, est particulièrement séduisante pour construire un système moderne.

Les technologies associées sont largement regroupées sous la dénomination de service mesh, parmi lesquels Istio, linkerd ou bien Consul. A la marge, des orchestrateurs réseau pour kubernetes, tels que Cilium, offrent des propriétés de sécurité du trafic entre les applications du cluster.

Ces technologies ont un point commun principal : elles reposent pour leur fonctionnement sur des primitives supposées sécurisées, quelques-unes sur une infrastructure de gestion de clés, et toutes sur un orchestrateur, le plus souvent kubernetes (certaines supportent également Swarm ou Nomad).

Or, la sécurisation de la couche d’orchestration, en particulier à travers Internet sans disposer de réseau sécurisé sous-jacent, est une tâche délicate. Les guides de sécurisation existent, mais tous ne sont pas toujours applicables. Par exemple, k3s, une distribution de kubernetes allégée – aujourd’hui employée dans hepto –, ne supporte pas TLS sur les connexions du master vers les nodes kubernetes.

Pour ces raisons principalement, la mise en oeuvre de l’approche zero-trust pour hepto est repoussée.

VPN et mesh

Pour qu’une surcouche réseau à base de VPN soit efficace, il faut que le trafic circule entre les noeuds sans transiter par un noeud central. Il faut également que tous les noeuds puissent échanger avec tous les autres noeuds, et que chacun puisse disposer d’un espace d’adressage complet pour les applications hébergées.

Une telle infrastructure, dénommée VPN full-mesh, n’est pas triviale à mettre en place. C’est en reprenant et en étendant un logiciel existant, « wesher », que hepto parvient à gérer un VPN full-mesh entre l’ensemble des noeuds garantissant la confidentialité et l’intégrité du trafic échangé, et servant de base à la surcouche orchestration.

Orchestration

Dernière modification January 1, 0001