Verschlüsselung schützt zwei unterschiedliche Dinge
Kubernetes-Backups können Secrets, Service-Account-Tokens, Registry-Zugangsdaten, Datenbankpasswörter, TLS-Zertifikate, RBAC-Zuweisungen und Daten aus Persistent Volumes offenlegen. Verschlüsselung kann die Auswirkungen von verlorenen Medien, offengelegten Buckets, gestohlenen Festplatten oder unautorisiertem Repository-Zugriff verringern — schafft aber auch eine neue Abhängigkeit für die Wiederherstellung. Ein verschlüsseltes Backup kann vollständig und strukturell intakt sein und trotzdem unbenutzbar bleiben, weil das Repository-Passwort verloren ging, die Verschlüsselungskonfiguration mit der Control Plane verschwand oder der KMS-Schlüssel gelöscht wurde.
Eine solide Strategie schützt zwei Dinge gleichzeitig:
Verschlüsselung kann auf mehreren Ebenen ansetzen — API-Daten, bevor sie in etcd gespeichert werden, etcd-Snapshot-Dateien, Velero-Backup-Daten, Objektspeicher, Snapshots von Persistent Volumes oder datenbankeigene Backup-Dateien. Diese Ebenen sind nicht austauschbar; ein vollständiges Design nutzt typischerweise mehrere davon gemeinsam.
Verschlüsselung während der Übertragung versus im Ruhezustand
Verschlüsselung während der Übertragung schützt Backup-Daten, während sie zwischen Kubernetes und Objektspeicher, Node-Agents und Backup-Repositories oder einem Wiederherstellungs-Cluster und S3-kompatiblem Speicher übertragen werden. Für diese Verbindungen wird üblicherweise TLS genutzt, aber der Schutz endet, sobald die Übertragung abgeschlossen ist — das Ziel benötigt weiterhin geeignete Verschlüsselung im Ruhezustand und Zugriffskontrolle.
Verschlüsselung im Ruhezustand schützt gespeicherte Informationen — etcd, etcd-Snapshots, Backup-Dateien von Kubernetes-Ressourcen, Backups von Persistent Volumes, Objektspeicher-Buckets und Archiv-Ebenen. Eine ausgereifte Strategie berücksichtigt beides.
Kubernetes Secrets werden nicht automatisch in etcd verschlüsselt
Die Werte von Kubernetes Secrets sind base64-kodiert, aber Kodierung ist keine Verschlüsselung.
Die aktuelle Kubernetes-Dokumentation weist darauf hin, dass Secrets standardmäßig unverschlüsselt in etcd gespeichert werden, sofern keine API-Datenverschlüsselung konfiguriert ist. Jeder mit passendem API- oder direktem etcd-Zugriff kann sie möglicherweise abrufen.
Das hat direkte Auswirkungen auf Backups — ein etcd-Snapshot kann lesbare Secret-Daten enthalten, wenn die API-Verschlüsselung im Ruhezustand nicht aktiviert ist, die Ressource nicht von der Verschlüsselungsrichtlinie erfasst wurde oder Daten schon vor der Aktivierung der Verschlüsselung existierten und nie neu geschrieben wurden. Behandeln Sie etcd-Snapshots als hochsensible Backup-Daten.
Lokale Schlüssel versus KMS v2
Die Kubernetes-Verschlüsselungskonfiguration nutzt eine geordnete Provider-Liste — der erste Provider wird normalerweise für neue Schreibvorgänge verwendet, ältere Provider können aber weiterhin nötig sein, um ältere Daten zu entschlüsseln. Wird ein alter Provider zu früh entfernt, können historische etcd-Daten und alte Snapshots unlesbar werden. Behandeln Sie Schlüsselrotation nicht als sofortige Schlüsselvernichtung.
Was Velero verschlüsselt — und was nicht
Der Schutz durch Velero kann mehrere unterschiedliche Datenkategorien umfassen, die jeweils unterschiedliche Verschlüsselungsmechanismen nutzen können.
Velero erstellt ein velero-repo-credentials-Secret, das das Repository-Passwort enthält. Das Passwort kann geändert werden, bevor das erste Backup ein Repository erstellt — eine spätere Änderung kann verhindern, dass Velero auf ältere Repositories zugreifen kann.
Damit wird das Repository-Passwort zu einer dauerhaften Wiederherstellungsabhängigkeit für bestehende Backups. Bewahren Sie die einzige Kopie nicht innerhalb von Kubernetes auf — der Quell-Cluster ist während der Wiederherstellung möglicherweise nicht verfügbar. Führen Sie eine operative Kopie für Velero und eine geschützte, unabhängig aufbewahrte Notfallkopie.
Verschlüsselungsmodelle für Objektspeicher
Prüfen Sie für den jeweiligen S3-kompatiblen Provider unterstützte Verschlüsselungsmodi, KMS-Integration, Verschlüsselung von Multipart-Uploads, Replikationsverhalten und Schlüsselrotation — S3-Kompatibilität garantiert kein identisches Verschlüsselungsverhalten zwischen Anbietern.
Verschlüsselung, Unveränderlichkeit und Integrität lösen unterschiedliche Probleme
Schützt die Vertraulichkeit. Ein verschlüsseltes Backup kann trotzdem gelöscht werden.
Schützt einen Wiederherstellungspunkt für einen bestimmten Zeitraum vor Änderung oder Löschung. Ein unveränderliches Backup kann trotzdem von einer autorisierten Identität gelesen werden.
Belegt, dass das Backup vollständig, unbeschädigt und anwendungskonsistent ist — Verschlüsselung belegt nichts davon.
Ein widerstandsfähiges Kubernetes-Backup benötigt typischerweise alle drei, dazu historische Aufbewahrung, separate Zugangsdaten und Offsite-Speicherung. Das umfassendere Framework beschreibt die 3-2-1-1-0-Backup-Regel.
Schlüssel-Inventar, Speicherung, Rotation und Außerbetriebnahme
Ein Kubernetes-Wiederherstellungspunkt kann von mehreren gleichzeitigen Schlüsseln abhängen — dem Verschlüsselungsschlüssel des API-Servers, einem externen KMS-Schlüssel, dem Velero-Repository-Passwort, einem Customer-Managed Key des Objektspeichers, einem Datenbank-Backup-Schlüssel und einem Guest-OS-Wiederherstellungsschlüssel für auf Kubernetes gehostete VMs. Die effektive Backup-Aufbewahrung wird durch den kurzlebigsten erforderlichen Schlüssel begrenzt: Ein ein Jahr lang aufbewahrtes Backup ist unbenutzbar, wenn sein Entschlüsselungsschlüssel bereits nach drei Monaten abläuft.
Wo der einzige Schlüssel nicht aufbewahrt werden sollte
Rotation und Außerbetriebnahme
Schlüsselrotation führt einen neuen Schlüssel für künftige Verschlüsselung ein — historische Backups werden dadurch nicht automatisch neu verschlüsselt. Bestimmen Sie vor der Rotation, welche Backups noch den alten Schlüssel nutzen und wie lange dieser verfügbar bleiben muss. Vernichten Sie den letzten Schlüssel erst, nachdem Sie bestätigt haben, dass kein benötigtes Backup, Archiv, keine regionsübergreifende Kopie und kein Legal Hold mehr davon abhängt — die Vernichtung des letzten Schlüssels ist faktisch eine unwiderrufliche Datenlöschung.
Clusterübergreifende, cloudübergreifende und Air-Gapped-Wiederherstellung
Ein Ersatz-Cluster kann sich in Cloud-Konto, Region, KMS, Kubernetes-Version oder Storage-Provider unterscheiden. Objektspeicher-Zugriff allein beweist noch keine Entschlüsselbarkeit — testen Sie, ob der Ersatz-Cluster tatsächlich das KMS, die API-Verschlüsselungskonfiguration, Datenbankschlüssel und erforderliche Zertifikate erreichen kann.
Eine Air-Gapped-Wiederherstellungsumgebung hat möglicherweise überhaupt keinen Zugriff auf Cloud-KMS oder externe Identität — bereiten Sie Offline-Schlüsselkopien, freigegebene Wiederherstellungssoftware und ein manuelles Verfahren zum Schlüsselimport vor, und testen Sie diese Materialien, bevor Sie sich darauf verlassen.
Sechs Stufen beim Testen verschlüsselter Backups
Häufige Fehler bei der Kubernetes-Backup-Verschlüsselung
Die Werte von Kubernetes Secrets werden durch base64 kodiert, nicht verschlüsselt. Konfigurieren Sie geeignete API-Datenverschlüsselung und Backup-Schutz.
Snapshot-Dateien können sensiblen Cluster-Zustand offenlegen. Verschlüsseln und beschränken Sie sie separat.
Die etcd-Daten können unlesbar bleiben. Bewahren Sie geschützte, unabhängige Kopien auf.
Bei Cluster-Verlust gehen sowohl der Backup-Client als auch der Entschlüsselungspfad verloren. Führen Sie externe Wiederherstellungskopien.
Ältere Repositories können unzugänglich werden. Planen Sie Passwortänderungen vor der Repository-Erstellung.
Historische Backups können noch von ihm abhängen. Stimmen Sie die Schlüssel-Aufbewahrung auf die Backup-Aufbewahrung ab.
Ein Identitätsausfall kann die Wiederherstellung blockieren. Nutzen Sie das Notfall-Wiederherstellungskonto.
Verschlüsselte Backups können trotzdem gelöscht werden, und verschlüsselte Daten können trotzdem unvollständig oder beschädigt sein. Stellen Sie sie wieder her und validieren Sie sie.
Dokumentationssysteme sind möglicherweise keine geeigneten Secret-Speicher. Halten Sie nur Kennungen und geschützte Speicherorte fest.
Alte Wiederherstellungspunkte können unbemerkt unbenutzbar werden. Stellen Sie nach der Rotation einen älteren Punkt wieder her.
Checkliste zur Kubernetes-Backup-Verschlüsselung
0 / 26Häufig gestellte Fragen
Sensible, offsite gespeicherte, gehostete, Cloud-, Wechselmedien- oder Shared-Infrastructure-Backups sollten je nach Risiko und Wiederherstellungsanforderungen auf Verschlüsselung geprüft werden.
Nein. Die aktuelle Kubernetes-Dokumentation weist darauf hin, dass Secrets standardmäßig unverschlüsselt in etcd gespeichert werden, sofern keine API-Datenverschlüsselung konfiguriert ist.
Nein. Base64 ist ein Kodierungsformat und bietet keine Vertraulichkeit.
Sie verschlüsselt ausgewählte API-Ressourcen, bevor sie in etcd gespeichert werden.
KMS v2 ist die stabile Envelope-Encryption-Integration von Kubernetes zum Schutz von API-Daten mittels Datenverschlüsselungsschlüsseln, die durch einen von einem KMS verwalteten Schlüsselverschlüsselungsschlüssel gesichert werden.
Nein. Daten in Persistent Volumes benötigen eine Verschlüsselung auf Storage-, Dateisystem-, Anwendungs- oder Backup-Repository-Ebene.
Die Backup-Komponenten von Velero nutzen unterschiedliche Mechanismen. Kubernetes-Ressourcendaten und Provider-Snapshots verlassen sich möglicherweise auf die Verschlüsselung des Storage-Providers, während Filesystem-Backup und CSI-Datenbewegung Repositories nutzen, die durch Repository-Zugangsdaten geschützt sind. Prüfen Sie die installierte Version und das Verhalten des Providers.
Es handelt sich um die Zugangsdaten, die von Veleros Filesystem-Backup- oder Snapshot-Datenbewegungs-Repositories genutzt werden. Sie müssen für jeden abhängigen Wiederherstellungspunkt verfügbar bleiben.
Es kann konfiguriert werden, bevor das erste Repository erstellt wird. Die Velero-Dokumentation warnt, dass eine Änderung nach der Repository-Erstellung den Zugriff auf ältere Backups verhindern kann.
Jedes Backup oder jede API-Ressource, die noch von diesem Schlüssel abhängt, kann dauerhaft unlesbar werden.
Sie schützt die Vertraulichkeit. Sie verhindert weder das Löschen von Backups noch Beschädigung, böswillige Konfigurationsänderungen oder die Wiederherstellung kompromittierter Daten.
Stellen Sie Kubernetes-Ressourcen und persistente Daten mit unabhängig geschützten Zugangsdaten und Schlüsseln in einem isolierten Ersatz-Cluster wieder her und validieren Sie anschließend die komplette Anwendung.
Vertraulichkeit schützen und den Wiederherstellungspfad erhalten
Kubernetes-Backup-Verschlüsselung sollte unautorisierten Zugriff verhindern, ohne ein unwiederherstellbares Archiv zu erzeugen. Verschlüsseln Sie sensible API-Daten, schützen Sie etcd-Snapshots, verschlüsseln Sie Backup-Übertragungen und Repositories, und verstehen Sie, welche Velero-Daten durch den Storage-Provider geschützt sind und welche durch ein Repository-Passwort.
Bewahren Sie operative und Notfall-Wiederherstellungsmaterialien getrennt vom Quell-Cluster auf, stimmen Sie die Schlüssel-Aufbewahrung auf die Backup-Aufbewahrung ab und stellen Sie dann einen historischen verschlüsselten Wiederherstellungspunkt in einem Ersatz-Cluster wieder her, ohne den ursprünglichen Administrator, Node oder die einzige lokale Schlüsselkopie zu verwenden. Verschlüsselung ist nur dann erfolgreich, wenn unautorisierte Parteien das Backup nicht lesen können, autorisierte Wiederherstellungsteams aber weiterhin schon.