Ein Raspberry-Pi-VPN-Gerät neu aufbauen, ohne seinen Schlüssel zu kopieren

Einmaliges Booten von einem Image macht aus einem Pi noch kein wiederaufbaubares Gerät. Nötig ist ein kleiner Satz von Eingaben, die sich erneut anwenden lassen: eine gepflegte Basis, eine deklarierte Konfiguration, die persistenten Daten der Anwendung und eine Geräteidentität, die nur zu diesem Board gehört. Wer den letzten Punkt vergisst, erzeugt mit jedem Ersatz einen Klon eines Zugangsdatensatzes.

Die folgenden Schritte sind eine Arbeitsreihenfolge, keine Werkzeugempfehlung. Jedes Konfigurationssystem, das sie ausdrücken kann, ist geeignet.

Zuerst die vier Arten von Eingaben auflisten

Das Basis-Image und seine Pakete legen Betriebssystem, Architektur und die Herkunft der Updates fest, und ein Image-Builder hilft nur, wenn das genannte Werkzeug für die eigene Version noch gepflegt wird. Die deklarierte Konfiguration ist der Teil, den ein Mensch prüft: Netzwerkrollen, Diensteinstellungen und die Lebenszyklusaktionen, die jeder Dienst braucht. Persistente Anwendungsdaten sind alles, was der Dienst nicht neu erzeugen kann, und ihr Ort und ihre Sicherungsmethode gehören zur Anwendung, nicht zum Image. Geräteidentitäten und Geheimnisse sind die vierte Eingabe, und genau sie vergisst man, wenn man eine laufende Karte klont.

Die vier Listen schreiben, bevor irgendetwas neu aufgebaut wird. Eine Liste mit einer leeren Zeile ist eine Entscheidung, die noch nicht getroffen wurde.

Geheimnisse aus dem Repository heraushalten und sagen, wo sie liegen

Ein Repository ist ein guter Ort für geprüfte Vorlagen und nicht-geheime Konfiguration und ein schlechter Ort für private VPN-Schlüssel, wiederverwendbare Administratoren-Zugangsdaten und Diagnosearchive. Muss ein Geheimnis auf dem Gerät existieren, ist festzuhalten, woher es kommt, wer es lesen darf und wie es rotiert wird. Ein Schlüssel, der nur auf einer SD-Karte liegt, ist ein einzelner Ausfallpunkt, während ein auf jedes Board kopierter Schlüssel ein flottenweiter Zugangsdatensatz ohne Eigentümer ist. Beides ist kein Wiederherstellungsplan.

Der Test ist einfach: Wenn das Repository morgen leckt, was gewinnt ein Angreifer? Vorlagen und Topologie-Notizen überleben. Eine funktionierende Identität nicht.

Automatisierung soll besitzen, was sie erneut ausführen kann

Das Modell von Ansible hält ein Inventar verwalteter Knoten getrennt von Plays, Tasks, Rollen und Handlern, die auslösen, wenn eine Task eine Änderung meldet. Mit dieser Struktur lässt sich jedem Dienst ein Konfigurationseigentümer geben, statt eine Shell-Historie erneut abzuspielen. Operationen bevorzugen, die sich gefahrlos zweimal ausführen lassen, und bewusst entscheiden, wie eine geänderte Datei den laufenden Prozess erreicht. Eine Task, die den Start eines Dienstes sicherstellt, bringt ihn nicht unbedingt dazu, eine gerade umgeschriebene Konfiguration neu zu laden.

Auch die Phasen der Administration trennen. Bootstrap-Konnektivität, Routenkonfiguration und VPN-abhängige Verwaltung sind drei verschiedene Fenster, und das dritte kann den eigenen Zugang entfernen, wenn der Neuaufbau das Netzwerk darunter zurücksetzt. Einen unabhängigen Weg hinein behalten.

Daten und Identität gezielt wiederherstellen

Container-Volumes bestehen unabhängig vom Lebenszyklus des Containers fort, die beschreibbare Schicht im Container dagegen nicht, weshalb das Neuerstellen eines Containers aus seinem Image nicht den Zustand wiederherstellt, den die Anwendung genutzt hat, wie die Volume-Dokumentation beschreibt. Die Volumes, Bind-Mounts und externen Dienste erfassen, von denen das Gerät abhängt, und den eigenen Sicherungs- und Wiederherstellungsprozess der Anwendung nutzen. Ein Container, der ohne Fehler startet, ist kein Beweis dafür, dass Datenbank und Dateien übereinstimmen.

Bei der Identität entscheiden, ob dasselbe Gerät wiederhergestellt oder ein Ersatz registriert wird, denn das sind verschiedene Vorgänge mit verschiedener Aufräumarbeit.

Den Zugang des alten Peers abgleichen, bevor eine Identität anderswo aktiviert wird, und erst danach das neu aufgebaute Gerät in einer isolierten Umgebung oder Wiederherstellungsumgebung testen. Die erforderlichen Daten, die richtige Identität, einen Update-Pfad mit Eigentümer und die vorgesehene Netzwerkrichtlinie prüfen.

Ein bootfähiges Image ist eine von vier Eingaben, und es ist die am leichtesten reproduzierbare.