Ein VPN-Server-Image klonen, ohne seine Identität zu klonen

Das Image startet, der Dienst läuft an, und Clients verbinden sich. Das ist der Moment, innezuhalten und zu fragen, welche von zwei sehr verschiedenen Operationen gerade stattgefunden hat. Entweder stellt die Kopie ein logisches Gateway wieder her, das zuvor existierte, oder sie fügt der Flotte ein zweites Gateway hinzu. Beides ist legitim, und beides hat unterschiedliche Folgen für Identität und Zugriff. Eine Maschine, die sauber hochkommt, beweist keines von beiden.

Drei Bedingungen entscheiden die Antwort, und es sind die drei Eimer Material, die ein Image tragen kann. Sortieren Sie sie, bevor das Image gebaut wird, nicht nachdem es zweimal ausgerollt wurde.

Entscheiden Sie zuerst, welche der beiden Operationen Sie ausführen

Eine Wiederherstellung behält eine Dienstidentität. Die alte Instanz ist weg, Name und Zertifikat bleiben, und Clients vertrauen weiterhin demselben Endpunkt. Ein Hinzufügen erzeugt eine zweite Identität, die Clients, Protokolle und Widerruf alle unterscheiden müssen.

Der Unterschied ist nicht kosmetisch. Wenn zwei laufende Hosts dasselbe Gateway-Zertifikat präsentieren, kann ein Client sie nicht auseinanderhalten, ein Prüfpfad ebenso wenig, und der Widerruf dieses Zertifikats entfernt beide zugleich. Das mag genau das sein, was ein bewusstes Hochverfügbarkeitsdesign will, und es ist selten das, was eine eilige Image-Kopie beabsichtigt.

Die erste Entscheidung ist also ein Satz, aufgeschrieben, bevor das Image den Build-Host verlässt: Diese Kopie stellt Gateway A wieder her, oder diese Kopie wird Gateway B. Alles Weitere ist Buchhaltung gegen diesen Satz. Wenn niemand ihn schreiben kann, ist die Kopie nicht bereit zum Bauen.

Wiederverwendbare Eingaben, Identität und Befugnis, Bereitstellungszustand

Der wiederverwendbare Eimer ist der einfache: Pakete, geprüfte Konfiguration ohne Geheimnisse, Dienstvorlagen, Härtungseinstellungen. Dafür ist ein Image wirklich gut, und es lässt sich unbegrenzt reproduzieren.

Der Eimer für Identität und Befugnis ist der, in dem Kopien schiefgehen. Der private Schlüssel und das Zertifikat eines Gateways identifizieren dieses Gateway gegenüber jedem Client. Der Signaturschlüssel der Zertifizierungsstelle ist ein anderes Objekt mit anderer Macht: Er stellt Identitäten aus. Einem Aussteller zu vertrauen heißt nicht, dass jedes neue Gateway die Fähigkeit zum Ausstellen braucht, und den Signaturschlüssel in einem Image mitzuliefern verleiht diese Fähigkeit allem, was das Image lesen kann.

Der Eimer für den Bereitstellungszustand ist der, den Leute vergessen, weil er wie Konfiguration aussieht. Listener-Adressen, Adresspools, gepushte Routen, Resolver-Einstellungen und lokale Integration kodieren allesamt Annahmen über den ersten Host. Ein zweiter Knoten, der sie kopiert, kann aus einem Pool zuteilen, den bereits ein anderes Gateway besitzt, oder Clients auf eine Ressource zeigen lassen, die nur neben dem Original existiert.

Was ein neuer Knoten bekommen muss, und von wem

Ein eigenständig verwalteter Knoten sollte seine eigenen Anmeldedaten über den freigegebenen Registrierungsprozess erhalten, wobei die Signatur dort erfolgt, wo der Signaturschlüssel liegt, und nicht auf dem neuen Host. Halten Sie fest, welche Identität zurückgezogen werden kann, ohne die anderen Knoten zu stören; wenn die Antwort "alle" lautet, hat das Design eine Identität, die sich als zwei ausgibt.

Netzwerte verdienen dieselbe Behandlung. Wählen Sie einen Pool, eine Listener-Adresse und eine Menge gepushter Routen, die nicht mit dem bestehenden Gateway kollidieren, und schreiben Sie sie in die Bereitstellungseingaben statt ins Image. Die Eingabe ist prüfbar; das Image nicht.

Es gibt einen legitimen Zwischenfall. Ein unterstütztes Wiederherstellungs- oder Replikationsdesign darf bewusst eine logische Dienstidentität über Hosts hinweg beibehalten, mit kontrolliertem Zugriff auf die alte Kopie und einem Rotationsplan. Das ist eine Entscheidung mit einem Verantwortlichen, kein Standard, der passiert, weil das Image bequem war.

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

Der erste Befehl sagt Ihnen, welche Identität der Knoten tatsächlich präsentiert und wer sie signiert hat. Der zweite ist eine Ausgangsinventur, kein Beweis: Privates Material kann außerhalb dieses Verzeichnisses leben, in einer Anwendungsdatenbank oder in einer Snapshot-Schicht, die das laufende Dateisystem nicht mehr zeigt.

Was eine Kopie des Images still mit sich führt

Eine Datei aus der neuesten Revision eines Images zu löschen entfernt sie nicht aus älteren Revisionen, Layer-Caches oder Snapshots, die entstanden, während sie existierte. Deshalb müssen Images mit Anmeldedaten während ihrer gesamten Lebensdauer als sensible Objekte behandelt werden und nicht nur im Moment des Bauens.

Prüfen Sie den Image-Inhalt und die Bereitstellungseingaben als getrennte Fragen. Das Image beantwortet "was steckt in diesem Artefakt", die Eingaben beantworten "was wird diese Instanz beim ersten Start". Ein sauberes Image mit einem Bootstrap-Skript, das einen gemeinsamen Schlüssel holt, beantwortet die erste Frage gut und die zweite schlecht.

Halten Sie Wiederherstellungsimages, die rechtmäßig Geheimnisse enthalten, auf die Personen beschränkt, die sie brauchen, und halten Sie fest, wo sie gespeichert sind. Die Alternative, ein Image, das bequem ist, weil es ohne jede Bereitstellung funktioniert, ist dasselbe Image, das jedem, der es findet, die Identität des Gateways gibt. Nur eine dieser beiden Aufgaben erscheint in einem Build-Protokoll.

Zulassungsprüfungen vor der Produktion

Bevor der Knoten Verkehr annimmt, bestätigen Sie vier Dinge: die Identität, die er präsentiert, die Clients, die er annimmt, die Ressourcen, die er erreichen darf, und den Rückweg für die Adressen, die er ausgibt.

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

Prüfen Sie dann den negativen Fall, der Unfälle fängt: Hat der neue Knoten Administrator- oder Clientzugriff, der für das Original gedacht war? Eine kopierte Konfiguration kann einen zusätzlichen Client-Eintrag, eine geerbte Verwaltungsroute oder eine Push-Direktive tragen, die auf dem ersten Host Sinn ergab.

Wenn ein Image mit laufenden Geheimnissen bereits seine freigegebene Grenze überschritten hat, ersetzen Sie die Anmeldedaten und begrenzen Sie die Kopien. Die Datei aus dem letzten Build zu entfernen ist nicht dasselbe wie die Anmeldedaten außer Betrieb zu nehmen, die ältere Kopien noch halten, und die Lücke zwischen diesen beiden Tatsachen ist genau das Fenster, das ein Angreifer braucht.