Merge branch 'master' of git.deuxfleurs.fr:Deuxfleurs/site

src/Technique/Jalon/Interconnexion.md

@@ -52,6 +52,19 @@ Voici quelques solutions auxquelles je pense :
 Étant donné que toutes les machines sont adressables en IPv6, on pourrait imaginer continuer dans la lancée actuelle et enregistrer l'IPv6 publique plutôt que l'IPv4 privée. Il faudrait s'assurer que les applications fassent elles-même le TLS au niveau applicatif. Mais ça voudrait dire que les services seraient exposés sur Internet en IPv6 et que notre seule protection serait le controle d'authentification réalisée par l'application (pour l'auth) et le TLS applicatif pas oublié (pour le chiffrement - et l'auth potentiellement en mutual auth).
 On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le firewall des serveurs pour autoriser le trafic IPv6 global qu'entre serveurs de l'infra. Et seul les ports des services publics actuels seraient ouverts à tous en IPv6.
 
+**Avantages:**
+
+- Bye bye le NAT
+- Basé sur des protocoles standard
+- Conceptuellement "simple"
+
+**Inconvénients:**
+
+- Complexité de mise en place, car il faut s'assurer que **tous** les services internes du cluster utilisent une authentification et que celle-ci est bien configurée
+- Pas de défense en profondeur donc il restera toujours le risque d'un service mal configuré qui permet de compromettre le système
+- Certains services ne savent peut-être pas faire d'authentification ? Par exemple GlusterFS (pour l'instant on ne s'en est pas débarassés) est-il capable de faire du TLS entre les noeuds ?
+- Si on choisit de rajouter un firewall, sait-on le configurer automatiquement lorsque les services changes de machine/de port ?
+
 ### La *networking* : Ajouter un VPN
 
 Solution étudiée par TeDomum/ACID. Ils partent sur Wesher. Voici leur avis :
@@ -65,6 +78,39 @@ Solution étudiée par TeDomum/ACID. Ils partent sur Wesher. Voici leur avis :
 > 
 > Bref. On veut faire simple et efficace.
 
+Solutions possibles: Wireguard/[Wesher](https://github.com/costela/wesher), `tinc`, cjdns/yggdrasil.
+
+**Avantages:**
+
+- Indépendant de toute autre problématique sur le cluster
+- Sans doute la solution la plus rapide à déployer à partir de l'état actuel
+- Les services continuent à se parler sur un réseau normal (cf les remarques de TeDomum ci-dessus)
+- Si les services communiquent en TLS et s'authentifie les uns aux autres ça fait une 2e couche de sécurité
+
+**Inconvénient:**
+
+- Ajoute un niveau de complexité au niveau global
+- N'implémente pas de politique de sécurité entre les services du cluster
+- Consommateur de CPU à haut débit
+- Protocoles de routage non-standard dans le cas des protocoles à base de mesh
+- (Certains clients VPN ne sont dispo que sur archi x86)
+
 ### La *micro-service architecture* : utiliser un service mesh
 
 Consul Connect permet de reporter le problème de l'interconnexion des infrastructures non plus au niveau des applications mais au niveau du cluster. Une fois Consul et Consul Connect bien configuré, tout le trafic sera alors chiffré d'un micro service à un autre avec du TLS et de l'authentification mutuelle. Consul sera lui même en charge de trouver comment faire communiquer les éléments. 
+
+**Avantages:**
+
+- Solution bien intégrée avec les autres outils Hashicorp (Nomad et Consul)
+- Sécurisation supplémentaire à base d'intent et d'ACL
+- Gestion intégrée du nommage, du routage et de la sécurité
+
+**Inconvénients:**
+
+- Nécessite sans doute pas mal de travail pour le mettre en place
+- Ajoute un outil potentiellement complexe et peu maîtrisé
+- Les applications ne se parlent plus directement sur le réseau -> problèmes dans certains cas (par exemple Garage peut-il toujours fonctionner?)
+- Consommateur de CPU à haut débit
+- Protocole encore moins standard que le VPN (en estimant que si Wireguard a atterri dans le noyau, c'est que c'est relativement standard quand même)
+
+**Conclusion:** L'arbitrage entre la solution VPN et la solution service mesh se fait sur les deux points suivants: outil permettant de sécuriser les connections en les autorisant au cas-par-cas (ACL+intent) vs. outil permettant de préserver un fonctionnement comme en LAN et où les applications peuvent utiliser les propriétés d'un tel réseau "classique".