Sortir du "nuage" mais rester "as Code"

Bonjour,

Enough est un CHATONS mais c’est aussi une instance de l’infrastructure as code qui est au cœur du projet. Quand une organisation veut « utiliser Enough » elle a le choix entre utiliser l’instance publique https://enough.community et faire confiance aux personnes qui la maintiennent. Ou bien d’exécuter le code sur ses propres machines pour éliminer un intermédiaire technique susceptible de trahir leur confiance. Non seulement c’est une bonne idée pour éviter les fuites. Mais en plus c’est moins stressant pour les mainteneurs bénévoles d’un service public qui contiendrait beaucoup de données confidentielles, merci pour nous :slight_smile:

Ça ressemble à un équilibre idéal, mais ce serait trop beau si ça couvrait tous les cas de figure. Quand le modèle de menace et le degré de maturité d’une organisation se satisfait d’héberger des services sur des machines opérées par des tiers (i.e. les nuages), alors c’est parfait. A titre d’exemple, si une organisation utilise les services de Google et Zoom au quotidien, basculer sur une instance Enough qu’elle contrôle avec Nextcloud et Jitsi est une amélioration sensible, quel que soit son modèle de menace.

Mais une fois que cette indépendance est acquise et qu’on se penche de nouveau sur le modèle de menace, il est possible qu’on arrive à la conclusion qu’OVH ou Fuga (les deux fournisseurs de machines virtuelles OpenStack sur lesquels repose Enough) présentent un risque qu’il convient d’écarter. Quand on sait que le fournisseur de machines virtuelles a littéralement le contrôle du processeur et du disque de la machine, chiffrer les échanges n’est pas la solution. Il faut impérativement en sortir et migrer les services sur des machines physiques.

C’est pour ces cas, rares mais impossibles à écarter, que SecureDrop fait partie des services d’Enough. Pour l’installer il faut (en gros) acheter le matériel, trouver ou le brancher et suivre la procédure d’installation. On est loin de l’infrastructure as code et les deux peuvent co-exister dans une organisation en vivant leur vie sans aucun lien.

Mais, et j’en viens à ce qui me préoccupe, il devrait exister un chemin pour aller de l’un à l’autre, pour sortir du « nuage » et aller sur des machines physiques, sans que les méthodes soient totalement différentes. Par exemple on peut imaginer un collectif de journalistes qui se contente parfaitement d’être sur les machines virtuelles de Fuga pendant plusieurs années. Jusqu’au jour ou il s’engage dans une longue enquête dans laquelle Fuga est impliqué. Il décide de sortir de Fuga pendant ce temps et de déplacer tous ses services sur des machines physiques: l’effort est conséquent, il faut acheter le matériel, trouver un hébergement, et faire la migration. Et quand l’enquête est terminée, le collectif peut être tenté de se débarrasser des machines physiques pour retourner dans le « nuage ».

La voie dans laquelle j’envisage d’aller pour tracer ce chemin consiste à faire tourner des machines virtuelles sur les machines physiques en les gérant avec libvirt et KVM, parce qu’ils partagent avec OpenStack un format d’échange (qcow2) de machines virtuelles qui permet, justement, de passer de l’un à l’autre avec un minimum de friction. C’est bien sur plus lourd qu’utiliser des containers (LXC, Docker, K8S) mais cela permet de réutiliser à l’identique le code de l’infrastructure: l’environnement physique est compatible avec l’environnement virtualisé.

C’est une réflexion en cours et rien n’est encore vraiment définitif, même si je suis assez convaincu que c’est la bonne direction. Mais c’est aussi ce qui me motive a l’exposer ici, pour le cas ou j’ai raté un problème évident. Je serais assez déçu, je ne le cache pas. Mais j’aime autant y faire face plus tôt que plus tard :slight_smile:

Qu’en dites vous ?

Cela m’a pas semblé vraiment très clair ce que tu veux faire ici.

1/ Si tu veux proposer une collection de playbook ansible permettant de déployer l’infra sur des machines virtualisées ou des machines physiques alors je pense que cela risque d’être compliqué à maintenir et à utiliser, d’autant plus qu’il y a aussi la couche réseau qui peut avoir un impact non négligeable.

2/ Si tu veux proposer directement des VM à déployer, alors oui cela est faisable même si je trouve que des containers sont mieux adaptés pour cela : plus légers, composables et intègrent nativement des mécanismes de configuration au démarrage.

1 Like

Uniquement des machines virtualisées. Quand ces machines virtualisées sont chez OVH, c’est eux qui les fabriquent. Quand ces machines virtualisées sont sur des machines physiques sous mon contrôle, c’est moi qui les fabrique. Effectivement, s’il s’agissait de gérer des machines physiques comme des machines virtualisées, ce serait un peu difficile.

J’ai toujours trouvé que c’était le point majeur de vigilance du « as code » dans Enought: la dépendance forte à une industrie difficile à reproduire indépendamment.

Le bon coté de ces interrogations c’est que c’est passionnant comme sujet.

Je vois 2 gros morceaux à déblayer. Et d’autres plus petits.

Difficulté de reproduire un hôte « modèle »

En quittant l’industrie on perd une forme d’homogénéïté. Avec openstack on a une machine neuve jamais servie en quelques minutes ; et c’est toujours la même, modulo quelques paramètres uniques (réseau, uuid disques, …).

Dans la vraie vie c’est différent, il est difficile de conserver de l’homogénéïté, surtout dans la durée : notre pouvoir d’achat et le volume impliqué n’est pas celui d’OVH, le matériel n’évolue pas suivant notre seul gré, les pannes imposent des substitutions partielles de l’équipement, etc.

La conséquence c’est que, même en étant précautionneux (installeur seedé, ansible), deux hôtes recevront rarement les mêmes logiciels et les mêmes paramétrages à l’octet près. Donc tout l’effort que tu déploieras à faire des tests de non-regression sur un modèle d’hôte ne te donneras que moins de garantie sur la façon dont ça va se passer en vrai, comparé à une solution 100% virtualisée. Donc la garantie que ta migration se finisse sans accroc n’est jamais acquise au même prix que dans un cas 100% nuagique.

Je n’ai pas trop de solution. On peut imaginer intercaler de la virtu avec libvirt/Qemu pour retrouver le paradis perdu du « nuagique[^1] », mais les couches basses conserveront cette tare. Ceci étant, si le fonctionnement en baremetal est uniquement temporaire ça posera moins de difficulté que s’il est pérenne : tu peux acheter des machines raisonnablement identiques et résoudre les pannes avec du matériel équivalent à l’achat initial.

Misère d’IP (v4)

Chez OVH t’as 1 IP par image Qemu. En quittant l’industrie tu risques fort de quitter l’abondance d’IPv4. Si tu as une seule IPv4 ça remet en cause ton architecture globale car il faut tout passer par un goulot d’étranglement : proxifier le web pour assurer le multiplexage, NATer le reste (DNS par exemple).

Et en plus ça se superpose mal avec IPv6. Chez chapril on n’arrive pas à faire du dualstack à cause du NAT et/ou à cause des services qui ne se proxifient pas bien (ex les services multimédia UDP). Car dans en IPv4 le fqdn du service résout sur le NAT et en IPv6, à défaut de proxy, le fqdn du service résout sur l’hôte qui est différent. Il faudrait peut être faire du NAT66 pour avoir une architecture qui superpose bien entre IPv4 et IPv6 mais on n’a pas encore osé. Et ça annihile une bonne partie des avantages d’IPv6.

En tout cas, sauf à se passer d’IPv4, ça va mettre une très forte pression sur l’architecture d’hébergement, qui est très cloisonné/distribuée chez Enough (au moins à l’époque où je m’inpliquais : on utilisait facilement une dizaine d’IPv4 ; je ne serais pas étonné qu’il y ait eu de l’inflation) et qu’il faudra rassembler/resserrer. Et si c’est le cas c’est une transformation importante. Et si ça impose une couche de virtualisation/conteneurisation, il faut que ça soit possible en nuagique aussi donc.

Sécurité du stockage, capacité de reprise sur erreur, firewalls

C’est des sujets loin d’être infaisables mais il va falloir les reprendre en mains et c’est du travail. En environnement nuagique c’est fourni de base avec le service.

[^1]: l’environnement physique est compatible avec l’environnement virtualisé

1 Like

C’est aussi ma conclusion, j’aime bien la façon de poser le problème. Pour chaque machine physique il y a forcément de la manutention et donc on perd le « as code », pas de mystère. En ajoutant de la virtualisation sur le physique, on peut de nouveau utiliser le « as code », pas 100% mais la plupart.

C’était une contrainte en effet, mais beaucoup moins maintenant: la plupart des services peuvent cohabiter sur une même VM, ce qui n’était pas le cas auparavant. Mais le nombre d’IP diminue aussi pour une autre raison: pour sécuriser une organisation il est sage de mettre les services dans un VPN (pour réduire la surface a surveiller) et donc d’y allouer des IP privées, disponibles en abondance.

Est-ce que tu comptes fournir des images de machines virtuelles ou fournir des scripts ansible permettant de déployer une infra à base de machines virtuelles ?

1 Like

Uniquement des scripts ansible permettant de déployer une infra à base de machines virtuelles. Soit dans un « nuage » OpenStack, soit fabriquées par libvirt sur une machine physique.

1 Like