Stellen wir uns vor, ein Server fällt aus. Ausgerechnet jetzt brauchen wir das Passwort, um die Umgebung wieder in Ordnung zu bringen. Der Passwortmanager liegt aber auf der betroffenen Infrastruktur. Spätestens in diesem Moment wird aus einer Architekturzeichnung eine sehr praktische Frage: Kommen wir noch an unsere Zugänge?
Mit dieser Frage im Hinterkopf haben wir Kubernetes mit Rancher und einem Vaultwarden-Piloten erprobt. Die folgenden Abschnitte erklären die beteiligten Rollen und Prüfungen an einem beispielhaften Aufbau. Sie beschreiben keine vollständige Architektur unseres produktiven Passwortmanagements.
Drei Werkzeuge, drei Aufgaben
Kubernetes übernimmt den Betrieb der Anwendungen. Ein möglicher Aufbau verwendet RKE2 mit drei virtuellen Maschinen auf getrennten physischen Hosts. Die Nodes übernehmen Aufgaben der Steuerebene und können Anwendungen ausführen. Eine solche Verteilung soll verhindern, dass bereits der Ausfall eines einzelnen Hosts die gesamte Steuerebene mitnimmt.
Rancher ist unsere Verwaltungsoberfläche. Dort sehen und verwalten wir den Cluster. Die Verfügbarkeit der Verwaltungsoberfläche betrachten wir getrennt von derjenigen der Anwendungen. Eine ausgefallene Rancher-Oberfläche bedeutet allerdings nicht automatisch, dass alle Anwendungen im verwalteten Cluster stehen bleiben. Für den Notfall brauchen wir zusätzlich einen geprüften direkten Administrationszugang. Diese Trennung beschreibt auch die Rancher-Dokumentation zum Weiterbetrieb verwalteter Cluster.
Vaultwarden ist die eigentliche Anwendung: der selbst betriebene Server für unseren Passwortmanager-Piloten. Auf dem Test-PC verwenden wir dafür die offizielle Bitwarden-Browsererweiterung. Verwaltungsoberfläche, Cluster und Passworttresor haben jeweils eigene Daten und eigene Wiederherstellungswege. Eine Sicherung von einem dieser Teile deckt die anderen nicht automatisch mit ab.
Der kleine Test, der mehr sagt als ein grüner Status
Container lassen sich neu starten. Bei einem Passworttresor müssen danach auch die richtigen Daten wieder da sein. Im beispielhaften Aufbau übernimmt Longhorn den persistenten Speicher mit über die Nodes verteilten Replikaten.
Einer der bisher aufschlussreichsten Tests war unspektakulär: Ein Testvolume bekam einen eindeutigen Inhalt. Wir haben es kontrolliert von einem Node getrennt und auf einem anderen wieder eingebunden. Der Inhalt war weiterhin lesbar und unverändert. Damit hatten wir einen konkreten Nachweis für diesen Speicherwechsel.
Dieser Speicherwechsel ist noch kein Stromausfalltest. Ein kontrolliertes Umhängen gibt dem System Zeit für einen geordneten Übergang. Beim plötzlichen Verlust eines Hosts müssen Fehlererkennung, Freigabe des Volumes und Neustart der Anwendung erst zusammenspielen. Dafür braucht es einen eigenen Test.
Warum drei Nodes allein nicht reichen
Die Zahl drei hat einen technischen Grund. Die etcd-Datenbank der Steuerebene benötigt eine Mehrheit; bei drei Mitgliedern sind das zwei. Das ermöglicht grundsätzlich den Weiterbetrieb beim Verlust eines Mitglieds, solange die verbleibenden Systeme kommunizieren können. Die RKE2-Anleitung für Hochverfügbarkeit beschreibt diese Grundlage und den gemeinsamen Registrierungsendpunkt.
Für den Menschen vor dem Browser beginnt Verfügbarkeit jedoch beim Aufruf der Adresse. DNS muss funktionieren, die HTTPS-Verbindung muss vertrauenswürdig sein und der Zugangsweg muss einen noch erreichbaren Node finden. Zeigt die Adresse fest auf den gerade ausgefallenen Rechner, helfen erreichbare Daten auf einem anderen Node zunächst wenig. Der gemeinsame Zugangsweg gehört deshalb ebenso auf unsere Prüfliste wie der Speicher.
Auch drei virtuelle Maschinen auf drei Hosts bleiben von gemeinsamem Netzwerk, Stromversorgung und weiteren Diensten abhängig. Wir prüfen deshalb die tatsächlichen Ausfallbereiche. Aus der Anzahl laufender VMs lässt sich keine Verfügbarkeitszusage ableiten.
Ein Passworttresor, drei Datenkopien
Ein einfacher Vaultwarden-Pilot kann eine einzelne Anwendungsinstanz mit SQLite und einem persistenten Volume verwenden. Drei Speicherreplikate sind dabei keine drei gleichzeitig schreibenden Vaultwarden-Instanzen. Speicherredundanz und Anwendungsredundanz lösen unterschiedliche Aufgaben.
Ein solcher Einstieg bleibt überschaubar. Bei einem Node-Ausfall ist das Ziel, die Anwendung mit ihren Daten auf einem anderen Node wieder zu starten. Wie lange das dauert und ob Anmeldung und Synchronisation danach funktionieren, muss ein Ausfalltest zeigen. Die Architektur allein belegt keine unterbrechungsfreie Umschaltung.
Eine kurze geplante Pause für ein brauchbares Backup
Replikation übernimmt auch unerwünschte Änderungen. Ein versehentlich gelöschter oder beschädigter Datenbestand kann auf mehreren Kopien gleichzeitig vorhanden sein. Für die Wiederherstellung eines früheren Zustands brauchen wir unabhängige Sicherungen. Longhorn unterscheidet entsprechend zwischen Replikaten und extern gespeicherten Backups.
Für einen solchen Aufbau lässt sich mit Restic verschlüsselt auf einen getrennten S3-Speicher sichern. In unserem getesteten Verfahren wurde die Anwendung kurz gestoppt, damit Datenbank und zugehörige Dateien zusammenpassten. Anschliessend startete Vaultwarden wieder, bevor die Übertragung zum Sicherungsziel erfolgte. Die kurze Unterbrechung gehört in die Wartungsplanung.
Eine manuelle Sicherung, das vollständige Lesen des Repositorys und die Rücksicherung von Dateien mit SQLite-Integritätsprüfung waren im Test erfolgreich. Diese Ergebnisse haben unterschiedliche Aussagekraft: Ein geprüfter Datenbestand ersetzt noch keinen vollständigen Anwendungsstart nach einer Wiederherstellung. Automatische Läufe, Standorttrennung und Anmeldung am wiederhergestellten Dienst brauchen jeweils eigene Prüfungen.
Eine weitere praktische Frage gehört dazu: Wo liegen die Schlüssel für die Wiederherstellung, wenn der Tresor selbst nicht erreichbar ist? Ein Notfallzugang muss unabhängig vom wiederherzustellenden System verfügbar und praktisch erprobt sein.
Der Browser gehört zum Betrieb
Am Test-PC haben wir Anmeldung mit Authenticator, Synchronisation in beide Richtungen, manuelles Sperren und Entsperren sowie gezieltes Formularausfüllen mit Dummy-Daten geprüft. Ein getrennter Test hilft, bestehende Kennwortbestände und neue Anmeldewege unabhängig voneinander zu prüfen.
Dabei gab es eine überraschend alltägliche Stolperfalle: Edge wechselte bei einer internen Website automatisch in ein anderes Browserprofil. Dort meldete sich wieder RoboForm, obwohl wir im separaten Profil Bitwarden testen wollten. Nach Abschalten des Intranet-Profilwechsels blieb der Test im vorgesehenen Arbeitsweg. Anschliessend wurden Benutzername und Passwort korrekt ins Formular eingesetzt. Die Dummy-Daten wurden nicht zur Anmeldung abgeschickt.
Der Server war bei diesem Problem erreichbar. Trotzdem kam der geplante Arbeitsablauf durcheinander. Für uns gehört deshalb auch der Client zur Betriebsabnahme: korrektes Profil, richtige Serveradresse und ein nachvollziehbarer Weg zum Entsperren und Ausfüllen.
Was sich für kleine KMU daraus ergibt
Wir betreuen kleine Unternehmen mit begrenzten Mitteln. Kubernetes bringt Möglichkeiten, aber auch zusätzliche Aufgaben: Clusterzustand, Speicher, Zertifikate, Sicherungen und Wiederherstellung müssen verstanden und gepflegt werden. Je nach Bedarf kann eine einfachere Containerumgebung wirtschaftlicher sein. Die passende Lösung hängt auch davon ab, wer sie im Störungsfall betreuen kann.
Für die Entscheidung über einen dauerhaften Betrieb gehören automatische Sicherung, vollständiger isolierter Restore und Ausfalltests zusammen. Der beschriebene Pilot lieferte konkrete Funktions- und Dateirücksicherungstests. Eine Übernahme produktiver Kennwörter verlangt eine gesonderte Bewertung der Wiederherstellungs- und Zugriffswege.