Cloner l'image d'un serveur VPN sans cloner son identité

L'image démarre, le service se lance et les clients se connectent. C'est le moment de s'arrêter et de demander laquelle de deux opérations très différentes vient de se produire. Soit la copie restaure une passerelle logique qui existait auparavant, soit elle ajoute une seconde passerelle à la flotte. Les deux sont légitimes, et elles ont des conséquences différentes pour l'identité et l'accès. Une machine qui démarre proprement ne prouve ni l'une ni l'autre.

Trois conditions décident de la réponse, et ce sont les trois catégories de matériel qu'une image peut porter. Triez-les avant que l'image soit construite, pas après qu'elle a été déployée deux fois.

Décidez d'abord laquelle des deux opérations vous effectuez

Une restauration conserve une identité de service. L'ancienne instance a disparu, le nom et le certificat restent, et les clients continuent de faire confiance au même point de terminaison. Un ajout crée une seconde identité que les clients, les journaux et la révocation doivent tous distinguer.

La distinction n'est pas cosmétique. Si deux hôtes actifs présentent le même certificat de passerelle, un client ne peut pas les distinguer, une piste d'audit non plus, et la révocation de ce certificat retire les deux à la fois. C'est peut-être exactement ce que veut une conception délibérée de haute disponibilité, et c'est rarement ce qu'a en tête une copie d'image pressée.

La première décision est donc une phrase, écrite avant que l'image quitte l'hôte de construction : cette copie restaure la passerelle A, ou cette copie devient la passerelle B. Tout le reste est de la comptabilité par rapport à cette phrase. Si personne ne peut l'écrire, la copie n'est pas prête à être construite.

Entrées réutilisables, identité et autorité, état de déploiement

La catégorie réutilisable est la plus simple : paquets, configuration revue sans secrets, modèles de service, réglages de durcissement. C'est là qu'une image est vraiment bonne, et elle peut être reproduite sans limite.

La catégorie identité et autorité est celle où les copies tournent mal. La clé privée et le certificat d'une passerelle identifient cette passerelle auprès de chaque client. La clé de signature de l'autorité de certification est un objet différent avec un pouvoir différent : elle émet des identités. Faire confiance à un émetteur ne signifie pas que chaque nouvelle passerelle ait besoin de la capacité d'émettre, et expédier la clé de signature à l'intérieur d'une image accorde cette capacité à tout ce qui peut lire l'image.

La catégorie état de déploiement est celle que les gens oublient parce qu'elle ressemble à de la configuration. Les adresses d'écoute, les pools d'adresses, les routes poussées, les réglages de résolveur et l'intégration locale encodent tous des hypothèses sur le premier hôte. Un second nœud qui les copie peut allouer depuis un pool qu'une autre passerelle possède déjà, ou diriger les clients vers une ressource qui n'existe qu'à côté de l'original.

Ce qu'un nouveau nœud doit recevoir, et de qui

Un nœud géré de façon indépendante devrait recevoir ses propres identifiants via le processus d'enrôlement approuvé, l'opération de signature se faisant là où vit la clé de signature plutôt que sur le nouvel hôte. Notez quelle identité peut être retirée sans perturber les autres nœuds ; si la réponse est "toutes", la conception a une identité qui prétend en être deux.

Les valeurs réseau méritent le même traitement. Choisissez un pool, une adresse d'écoute et un ensemble de routes poussées qui n'entrent pas en collision avec la passerelle existante, et écrivez-les dans les entrées de provisionnement plutôt que dans l'image. L'entrée est vérifiable ; l'image ne l'est pas.

Il existe un cas intermédiaire légitime. Une conception de récupération ou de réplication prise en charge peut délibérément conserver une identité logique de service entre plusieurs hôtes, avec un accès contrôlé à l'ancienne copie et un plan de rotation. C'est une décision avec un propriétaire, pas un défaut qui survient parce que l'image était pratique.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

La première commande indique quelle identité le nœud présente réellement et qui l'a signée. La seconde est un inventaire de départ, pas une preuve : le matériel privé peut vivre hors de ce répertoire, dans une base de données d'application, ou dans une couche d'instantané que le système de fichiers en cours d'exécution ne montre plus.

Ce qu'une copie de l'image transporte discrètement

Supprimer un fichier de la révision la plus récente d'une image ne le retire pas des révisions plus anciennes, des caches de couches ou des instantanés pris pendant qu'il existait. C'est pourquoi les images porteuses d'identifiants doivent être traitées comme des objets sensibles pendant toute leur durée de vie, et pas seulement au moment où elles sont construites.

Vérifiez le contenu de l'image et les entrées de provisionnement comme deux questions distinctes. L'image répond à "qu'y a-t-il dans cet artefact", tandis que les entrées répondent à "que deviendra cette instance au premier démarrage". Une image propre avec un script d'amorçage qui récupère une clé partagée répond bien à la première question et mal à la seconde.

Gardez les images de récupération qui contiennent légitimement des secrets réservées aux personnes qui en ont besoin, et notez où elles sont stockées. L'alternative, une image pratique parce qu'elle fonctionne sans aucun provisionnement, est la même image qui accorde l'identité de la passerelle à quiconque la trouve. Une seule de ces deux tâches apparaît dans un journal de construction.

Contrôles d'admission avant la production

Avant que le nœud prenne du trafic, confirmez quatre choses : l'identité qu'il présente, les clients qu'il acceptera, les ressources auxquelles il est autorisé à accéder et le chemin de retour pour les adresses qu'il distribue.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Vérifiez ensuite le cas négatif, celui qui attrape les accidents : le nouveau nœud a-t-il un accès administrateur ou client qui était destiné à l'original ? Une configuration copiée peut porter une entrée client supplémentaire, une route de gestion héritée ou une directive push qui avait du sens sur le premier hôte.

Si une image contenant des secrets actifs a déjà dépassé sa limite approuvée, remplacez les identifiants et contenir les copies. Retirer le fichier de la dernière construction n'est pas la même chose que retirer l'identifiant que les copies plus anciennes détiennent encore, et l'écart entre ces deux faits est exactement la fenêtre dont un attaquant a besoin.