Thema Verschlüsselung von VM, Dateien und Backups

[Stefan33]

Hallo,

ich möchte, dass meine Daten in der Windows-VM und im SAMBA-LXC verschlüsselt werden, verstehe jedoch noch nicht den Zusammenhang der Möglichkeiten und bitte um Hilfe.

Wenn ich meine VM und den LXC mit den Daten verschlüsseln möchte, dann könnte ich das recht einfach mit der Verschlüsselungsfunktion von ZFS machen, wenn ich nicht folgende Aussage gefunden hätte:

Native ZFS Verschlüsselung in Proxmox VE ist experimentell. Bekannte Grenzen und Probleme sind Replikation mit verschlüsselten Datensätzen [33] sowie Prüfsummenfehler bei Snapshots oder ZVOLs. 4[4]

Da ein Cluster und Auto-Snapshots zum Einsatz kommen soll, entfällt somit die einfache Möglichkeit über ZFS zu verschlüsseln, oder ist die Information mit der aktuellen ZFS-Version überholt?

Eine weitere Möglichkeit innerhalb der Windows-VM, wäre die Verschlüsselung mit BitLocker. Doch soweit ich gelesen habe, macht das auch wieder Probleme bei der Sicherung, da das inkrementelle Backup vom PBS dann nicht mehr funktioniert?
Dies wäre in meinem Fall auch wieder fatal, da ein PBS2 im entfernten Gebäude zum Einsatz kommen soll und ich zwingend nur das Delta sichern kann.

Ist das eine ausweglose Situation, oder gibt es hier eine Lösung, die ich noch nicht erkannt habe?

Was mich noch bewegt...
Wenn ich eine Sicherung vom PVE auf den PBS mache, dann kann ich auswählen, ob die Backups verschlüsselt sein sollen, oder nicht. Ist diese Verschlüsselung die von ZFS, oder eine eigene?
Wenn es eine eigene Verschlüsselung ist und ich die Verschlüsselung in ZFS aktiviere, habe ich dann eine Verschlüsselung in der Verschlüsselung?
Wenn sich der PBS2(remote) mit PBS1(lokal) synchronisiert, bleibt dann das Backup von PBS1 auf dem PBS2 verschlüsselt?

Was wäre denn die Einfachste und Beste Lösung, um meine Daten zu verschlüsseln und verschlüsselt zu sichern?

Für jede Hilfe bedanke ich mich schon mal im Vorraus.

 

[fabian]

Hallo,

ich möchte, dass meine Daten in der Windows-VM und im SAMBA-LXC verschlüsselt werden, verstehe jedoch noch nicht den Zusammenhang der Möglichkeiten und bitte um Hilfe.

Wenn ich meine VM und den LXC mit den Daten verschlüsseln möchte, dann könnte ich das recht einfach mit der Verschlüsselungsfunktion von ZFS machen, wenn ich nicht folgende Aussage gefunden hätte:

Da ein Cluster und Auto-Snapshots zum Einsatz kommen soll, entfällt somit die einfache Möglichkeit über ZFS zu verschlüsseln, oder ist die Information mit der aktuellen ZFS-Version überholt?

nein, ZFS Native Encryption Bugs und Probleme existieren leider auch in der aktuellen ZFS Version noch..

Eine weitere Möglichkeit innerhalb der Windows-VM, wäre die Verschlüsselung mit BitLocker. Doch soweit ich gelesen habe, macht das auch wieder Probleme bei der Sicherung, da das inkrementelle Backup vom PBS dann nicht mehr funktioniert?

das Backup würde in dem Fall verschlüsselte Blöcke sichern, was sicher zu unnötig hohem Platzverbrauch führt (ich weiß nicht was genau die Auswirkungen bei Bitlocker sind), und je nach eingesetztem Tool bzw. dessen Implementierung unter Umständen auch zu Problemen beim Restore bzw. anschließendem Entschlüsseln.

Dies wäre in meinem Fall auch wieder fatal, da ein PBS2 im entfernten Gebäude zum Einsatz kommen soll und ich zwingend nur das Delta sichern kann.

Ist das eine ausweglose Situation, oder gibt es hier eine Lösung, die ich noch nicht erkannt habe?

LUKS/dm-crypt (das Standard Festplattenverschlüsselungsfeature von Linux) *unter* dem eigentlichen Storage wäre eine Option. Musst du allerdings auch von Hand aufsetzen (gibt hier im Forum einen längeren Thread dazu). Damit wäre der ganze Storage "at rest" verschlüsselt, aber sowohl PVE (inkl. Backup auf PBS) als auch die VM selbst sehen die Daten im Klartext.

Wenn ich eine Sicherung vom PVE auf den PBS mache, dann kann ich auswählen, ob die Backups verschlüsselt sein sollen, oder nicht. Ist diese Verschlüsselung die von ZFS, oder eine eigene?

das ist ein eigenes PBS-Feature: https://pbs.proxmox.com/docs/backup-client.html#encryption

Wenn es eine eigene Verschlüsselung ist und ich die Verschlüsselung in ZFS aktiviere, habe ich dann eine Verschlüsselung in der Verschlüsselung?

nein, weil das Backup aus Sicht des Qemu-Prozess passiert - wenn nicht die Ver-/Entschlüsselung in der VM drinnen passiert, sieht der die Daten im Klartext, d.h. es wird bei einem verschlüsseltem Backup auf PBS nur einmal durch den PBS-Client verschlüsselt.

Wenn sich der PBS2(remote) mit PBS1(lokal) synchronisiert, bleibt dann das Backup von PBS1 auf dem PBS2 verschlüsselt?

der PBS-Server kann verschlüsselte Backups nicht entschlüsseln, d.h. diese bleiben auch bei einem Sync gleich verschlüsselt.

 

[Stefan33]

Vielen Dank für die schnelle Rückmeldung und Erläuterung!

O.K., alle Wege die ich kenne machen Probleme...

Welcher Weg wäre in meinem Fall empfehlenswert?

 

[fabian]

wenn es dir darum geht das sowohl die daten an sich als auch die backups verschluesselt sind damit du bedenkenlos festplatten entsorgen kannst (oder beim hosting provider kuendigen), wuerde ich zu LUKS fuer PVE und verschluesselten PBS backups raten. eine verschluesselung innerhalb der VM macht meiner meinung nach selten sinn (ausser es zwingen einen richtlinien ausserhalb der eigenen einflusssphäre dazu). je nachdem wo und wie abgesichert dein PVE steht reicht unter umstaenden auch nur verschluesseltes PBS, aber das ist immer eine frage der eigenen anforderungen und analyse.

wichtig beim thema verschluesselung ist immer, sich auch gedanken ueber sicherung der zur entschluesselung notwendigen keys gedanken zu machen -> sonst stehst du im ernstfall dann mit nutzlosen verschluesselten backups ohne keys da.. eine gaengige variante waere z.b. auf papier im (bank-)safe.

 

[Stefan33]

Danke für deine Erläuterungen!

 

[selbitschka]

Ich verwende native ZFS Verschlüsselung inklusive Replikation und Backups seit einiger Zeit auf meinem Testsystem und habe gerade erst ein Update zu meinem Thread verfaßt, falls es dich interessiert:
https://forum.proxmox.com/threads/a...-on-zfs-encrypted-storage.117227/#post-520078

Allgemein funktioniert native ZFS encryption ohne Probleme mit Proxmox und es wären mir noch keine Nachteile aufgefallen.

Wichtig ist halt das du entweder die VMs nicht automatisch startest oder eine keys über ein script beim boot lädtst.

lg
stefan

 

[Stefan33]

Ich verwende native ZFS Verschlüsselung inklusive Replikation und Backups seit einiger Zeit auf meinem Testsystem und habe gerade erst ein Update zu meinem Thread verfaßt, falls es dich interessiert:
https://forum.proxmox.com/threads/a...-on-zfs-encrypted-storage.117227/#post-520078

Allgemein funktioniert native ZFS encryption ohne Probleme mit Proxmox und es wären mir noch keine Nachteile aufgefallen.

Wichtig ist halt das du entweder die VMs nicht automatisch startest oder eine keys über ein script beim boot lädtst.

lg
stefan

Vielen Dank für deinen Beitrag!

Offen gestanden bin ich mit deiner Ausführung völlig überfordert.

Was bedeutet das für mich mit einfachen Worten in der Praxis?
Wenn ich die Autostart-Funktion der VM`s und LXC`s nicht nutze, dann "umgehe" ich den Bug und kann die ZFS-Verschlüsselung fehlerfrei nutzen?

 

[fireon]

Allgemein funktioniert native ZFS encryption ohne Probleme mit Proxmox und es wären mir noch keine Nachteile aufgefallen.

Nutze dies hier auf meinem Cluster auch schon fast 2 Jahre. Probleme sind mir noch nie aufgefallen. Benutzer auch Autosnapshot. Mach auch hin und wieder davon Rollbacks. Und die Snapshotfunktion im PVE Webinterface nutze ich auch für Entwicklung sehr oft.

Wichtig ist halt das du entweder die VMs nicht automatisch startest oder eine keys über ein script beim boot lädtst.

Ich geb die Phasphrase manuell beim Boot einfach über SSH ein. Hab in globalen Optionen ein Timeout von 5 Minuten eingestellt, dann kommt es zu keinem Error bei keinem verfrühten Start der VM's. Ich mach das immer so:

/poolname/safe/<zvol, oder dataset>

 

[Stefan33]

@fireon Vielen Dank für deine Erfahrung!

Nun habe ich dich mit deiner Erfahrung ohne Probleme, sofern man die VMs erst starten lässt, nachdem man das Passwort zur Entschlüsselung eingegeben hat.

und

ich habe die Erfahrung von selbitschka, der davon berichtet, dass die Migration und Replikation nicht richtig funktioniert.

Was kann denn schlimmstenfalls passieren, dass ein Snapshot oder Migrationsversuch scheitert, mehr nicht, oder?
Wenn jedoch die Backup-Jobs auch auf Basis von ZFS-send zum PBS gemacht werden, dann würde dies bedeuten, dass auch diese Backups von dem "Bug" betroffen sind?

Ich bin neu und ohne Erfahrung in der Linux / Proxmox-Welt und weiß nicht was ich nun tun soll?

 

[selbitschka]

Sorry ich wollte dich nicht verwirren!

Fakt ist das wenn du ein verschlüsseltes Dataset hast und darauf deine VMs ablegst geht out of the box die Replikation von Proxmox nicht. Das liegt daran, dass im Perl Script welches diese macht folgendes Command verwendet wird:
zfs send -Rpv ...

In der man page von zfs send (https://openzfs.github.io/openzfs-docs/man/8/zfs-send.8.html) steht zum Parameter -R:

If the -R flag is used to send encrypted datasets, then -w must also be specified.

Somit funktioniert das nicht ohne das script anzupassen, da zfs das nicht zulässt.
Hier gibt es dann 2 Varianten wie ich in meinem Thread (s.o.) beschrieben habe:

1. Unverschlüsselt und ohne Properties senden, also -R und -p weglassen (1. Variante)
2. Den Parameter -w mit aufnehmen (2. Variante) + Import anpassen.

Egal welchen weg du gehst es funktionieren danach alle Replikationen und Migrationen. Problematisch wird es wenn du zfs send als Backup verwendest denn dann hängt es im 1. Fall davon ab von welchem host du das Backup startest. Hast du von Host A begonnen kannst du von Host B keine inkrementellen Backups per Snapshot mehr machen, da die Verschlüsselung nicht passt. Die Daten sind zwar auf beiden Hosts verschlüsselt aber mit einem anderen Key da die Initialisierungs-Vektoren (IV) nicht übereinstimmen. In Variante 2 gibt es das Problem nicht, da mit der Option -Rpw alles gesendet wird - auch die IVs etc.. Ich kann das gerne mal weiter ausführen hab jetzt aber zu wenig Zeit dazu.

Du musst aber in beiden Varianten in den Code von Proxmox eingreifen (und das nach jedem Update), da sonst keine Replikation mit Proxmox Boradmitteln funktioniert.

Wenn du die Replikation nat. von Hand oder mit einem anderen Tool machst ist das alles kein Thema da du ja hier frei in der Gestaltung bist.

 

[fabian]

https://github.com/openzfs/zfs/issues/11679 waere ein beispiel fuer einen encryption bug der noch nicht gefixt ist.

 

[selbitschka]

So jetzt habe ich mehr Zeit und werde gerne bei der ZFS encryption etwas in die Tiefe gehen und erklären wo das Problem liegt.

Zum besseren Erläuterung spielen wir ein kleines Beispiel durch, erstellen 2 verschlüsselte Datasets mit gleichem Passwort und schauen uns dann die Verschlüsselungsparameter an:

zfs create -o compression=on -o encryption=aes-256-gcm -o keyformat=passphrase rpool/test1
zfs create -o compression=on -o encryption=aes-256-gcm -o keyformat=passphrase rpool/test2
zfs snapshot rpool/test1@init
zfs snapshot rpool/test2@init

Nun senden wir die beiden Snapshots durch zstreamdump und geben uns die Verschlüsselungsparameter aus:

zfs send -w rpool/test1@init | zstreamdump | sed -n -e '/crypt_keydata/,/end crypt/p; /END/q'
...
        DSL_CRYPTO_MASTER_KEY_1 = 0x28 0x21 0xa6 0x27 0xfc 0x18 0x17 0x5a 0x66 0x70 0x53 0xf1 0x37 0xd5 0xd7 0xc1 0x69 0x6d 0x6f 0x2c 0x4a 0xd7 0xd3 0xeb 0x1 0x5f 0xd8 0xdf 0x2a 0x18 0xef 0x3b
        DSL_CRYPTO_HMAC_KEY_1 = 0x1d 0xa6 0x47 0xee 0x29 0x4d 0xc6 0x37 0x74 0xce 0x51 0x9b 0xc5 0xee 0xda 0x7d 0x97 0x8a 0xe9 0x94 0x5f 0x87 0xb6 0x40 0xd7 0x73 0x48 0x21 0xcf 0x57 0x24 0x50 0x2d 0x6e 0x19 0x9f 0x39 0x9f 0x42 0xe9 0xb6 0x3 0xc 0xc1 0xd4 0xbb 0xc7 0xd8 0xb 0xc7 0xb2 0xd3 0xf8 0xd7 0x62 0x99 0xcc 0x73 0x35 0xac 0xb 0x78 0xdc 0x4d
        DSL_CRYPTO_IV = 0x6f 0x94 0xeb 0xd 0x4f 0xb0 0x61 0x7 0xb6 0xf1 0x53 0xee
...
zfs send -w rpool/test2@init | zstreamdump | sed -n -e '/crypt_keydata/,/end crypt/p; /END/q'
...
        DSL_CRYPTO_MASTER_KEY_1 = 0xeb 0x3a 0xcf 0x19 0xed 0x2e 0xbf 0x84 0xea 0xea 0xc0 0x68 0xf6 0x0 0xe1 0x70 0x61 0x74 0x38 0xc7 0x66 0x74 0xf9 0x54 0x93 0xa0 0xcd 0xdc 0xa5 0xb 0xcc 0x49
        DSL_CRYPTO_HMAC_KEY_1 = 0x17 0x49 0x80 0xd6 0xf1 0x4c 0xaa 0x7b 0x24 0xed 0xbd 0x6e 0xb1 0xfc 0xba 0x60 0xb5 0xb0 0x54 0x4e 0x79 0xac 0x31 0xc3 0x8a 0xef 0xf4 0x41 0xee 0x87 0xf0 0xe 0xf9 0x60 0x26 0x8a 0xc8 0x9 0xbc 0xdb 0x8f 0x5 0xd0 0xfb 0x96 0xb5 0xc5 0x7 0x62 0x3d 0xb2 0xc8 0x17 0xe2 0x60 0x16 0x24 0x67 0x1c 0x60 0x15 0xdd 0xa8 0xf7
        DSL_CRYPTO_IV = 0xa2 0x22 0xd0 0xc 0x59 0x8 0xfd 0x61 0xbf 0x8a 0xcf 0x8a
...

Wie man sieht sind die beiden Verschlüsselungsschlüssel DSL_CRYPTO_MASTER_KEY_1 und im speziellen auch der Initialisierungsvektor DSL_CRYPTO_IV unterschiedlich.

Das ist auch gut so, denn nur weil man das gleiche Passwort verwendet, darf die Verschlüsselung nicht gleich sein.

Das heißt aber nat. im Umkehrschluß, dass ein Snapshot von Dataset test1 nicht mit dem Schlüssel von Dataset test2 entschlüsselt werden kann. Das trifft auf Variante 1 zu wenn man ein Dataset unverschlüsselt in ein anderes verschlüsseltes Dataset transferiert zu. Was dazu führt das inkrimentelle Snapshot der beiden Dataset nicht kompatibel sind - das wird von ZFS mittlerweile auch bemerkt und es verhindert ein receive.

Wenn man nun aber nur ein Dataset anlegt und diese mit dem Parameter -w transferiert sieht die Sache anders aus:

zfs destroy -r rpool/test2
zfs send -Rpvw rpool/test1@init | zfs receive rpool/test2
zfs send -w rpool/test2@init | zstreamdump | sed -n -e '/crypt_keydata/,/end crypt/p; /END/q'
...
        DSL_CRYPTO_MASTER_KEY_1 = 0x28 0x21 0xa6 0x27 0xfc 0x18 0x17 0x5a 0x66 0x70 0x53 0xf1 0x37 0xd5 0xd7 0xc1 0x69 0x6d 0x6f 0x2c 0x4a 0xd7 0xd3 0xeb 0x1 0x5f 0xd8 0xdf 0x2a 0x18 0xef 0x3b
        DSL_CRYPTO_HMAC_KEY_1 = 0x1d 0xa6 0x47 0xee 0x29 0x4d 0xc6 0x37 0x74 0xce 0x51 0x9b 0xc5 0xee 0xda 0x7d 0x97 0x8a 0xe9 0x94 0x5f 0x87 0xb6 0x40 0xd7 0x73 0x48 0x21 0xcf 0x57 0x24 0x50 0x2d 0x6e 0x19 0x9f 0x39 0x9f 0x42 0xe9 0xb6 0x3 0xc 0xc1 0xd4 0xbb 0xc7 0xd8 0xb 0xc7 0xb2 0xd3 0xf8 0xd7 0x62 0x99 0xcc 0x73 0x35 0xac 0xb 0x78 0xdc 0x4d
        DSL_CRYPTO_IV = 0x6f 0x94 0xeb 0xd 0x4f 0xb0 0x61 0x7 0xb6 0xf1 0x53 0xee
...

Wie man hier erkennt stimmen der Key (DSL_CRYPTO_MASTER_KEY_1) und der Initialisierungsvektor (DSL_CRYPTO_IV) nun in beiden Dataset überein und die Daten sind mit den gleichen Schlüsseln verschlüsselt und die Snapshots kompatibel.

 

[selbitschka]

Nun schauen wir uns an was in Proxmox passiert wenn man das tut.
Wir erstellen 2 Dataset die unsere beiden Hosts darstellen, erstellen auf einem "host" eine verschlüsseltes Dataset "vm_enc" für unser VMs und transferieren das auf den anderne host (hier verkürzt auf einer Maschine dargestellt)

zfs create rpool/pve1
zfs create rpool/pve2
zfs create -o compression=on -o encryption=aes-256-gcm -o keyformat=passphrase rpool/pve1/vm_enc
zfs snapshot rpool/pve1/vm_enc@init
zfs send -Rpvw rpool/pve1/vm_enc@init | zfs receive -F rpool/pve2/vm_enc
zfs load-key rpool/pve2/vm_enc

Nun haben wir auf jedem Host ein Dataset für VMs mit gleichem Schlüsselmaterial. Als nächstes erstellen wir eine VM welche auf dem Host pve1 erstellt wir (hier als simples dataset und nicht als zvol) und schauen uns die für die Verschlüsselung wichtigen Eigenschaften an:

zfs create rpool/pve1/vm_enc/vm-100-disk-1
zfs list -o name,encryptionroot,keystatus

NAME                                ENCROOT              KEYSTATUS
...
rpool/pve1/vm_enc                   rpool/pve1/vm_enc    available
rpool/pve1/vm_enc/vm-100-disk-1     rpool/pve1/vm_enc    available
...

Wenn man sich dann auf dem neuen Dataset den Wert "ENCROOT" (für encryption root) ansieht, erkennt man, dass dieser vom darüberliegenden dataset geerbt wurde. Das heißt die Daten im VM Dataset (.../vm-100-disk-1) sind mit dem Schlüssel vom parent (.../vm_enc) verschlüsselt. Somit kann man die VM verwenden sobald das darunterliegende Datenset entschlüsselt ist.

Senden wir nun einen Replikationssnapshot zu unserem anderen host (unter Verwendung der Variante 2 mit dem Parameter -w) so schaut das Ergebnis auf dem 2. Host zunächst so aus:

zfs snapshot rpool/pve1/vm_enc/vm-100-disk-1@replication
zfs send -Rpvw rpool/pve1/vm_enc/vm-100-disk-1@replication | zfs receive -F rpool/pve2/vm_enc/vm-100-disk-1
zfs list -o name,encryptionroot,keystatus

NAME                                ENCROOT                            KEYSTATUS
...
rpool/pve2/vm_enc                   rpool/pve2/vm_enc                  available
rpool/pve2/vm_enc/vm-100-disk-1     rpool/pve2/vm_enc/vm-100-disk-1  unavailable
...

Wie man erkennt ist das encryption-root (ENCROOT) auf dem 2 Host nachdem der Snapshot empfangen wurde nicht mehr vererbt sondern das VM-Disk-Dataset selbst. Dies muss auch so sein, denn sonst könnte man einen Snapshot ohne dem darunterliegenen Dataset nicht alleine entschlüsseln. Des weiteren ist der KEYSTATUS "unavailable", da ZFS ja nicht weiß woher es nach dem Empfang das Passwort oder Keyfile nehmen soll.

Nun gibt es 2 Varianten das zu lösen:

1. Man sagt ZFS das es den Key wieder vom darüberliegenden Datset nehmen soll, denn diese sind dank der initialen Replikation ja gleich oder
2. man lässt das VM Dataset als encryption root und setzt dort nur die keylocation und lädt den Schlüssel.

Da sich beim ändern des Schlüssels mit zfs change-key viele Bugs aufgetan haben, habe ich mich in meiner Variante 2 für den zweiten Weg entschieden und lasse das VM Dataset sein eigenes encryption root sein und setzt dort entsprechend die keylocation.

Da nun aber jede VM Disk (spätestens nach Replikation, Migartion und Replikation zurück) sein eigenes Encryption-Root ist, müssen die Keys, selbst wenn sie als Datei auf der Disk liegen beim Booten geladen werden. Ich verwende hierzu eine Startup-Script welches alle Keys des VM datasets rekursiv läd und dieses mounted:

zfs set canmount=noauto tank/vmdata_enc

cat << 'EOF' > /etc/systemd/system/zfs-mount-enc@.service
[Unit]
Description=Mount encrypted ZFS dataset %I
Before=pve-manager.service
After=sysinit.target
After=zfs-import.target
Requires=zfs-import.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/sbin/zfs load-key -r %I
ExecStart=/sbin/zfs mount -l %I

[Install]
WantedBy=multi-user.target
EOF

systemctl enable zfs-mount-enc@tank-vmdata_enc
systemctl status zfs-mount-enc@tank-vmdata_enc
systemctl daemon-reload

Zusammengefasst ist es mit ein wenig Handarbeit ohne Probleme möglich Proxmox mit nativer ZFS Verschlüsselung zu verwenden. Wichtig hierbei ist aus meiner Sicht, dass man immer den Schlüssel im Dataset belässt, da so gut wie alle Bugs mit der ZFS Verschlüsselung auf unterschiedliche Verschlüsselungsschlüssel oder den Schlüsseltausch mittels zfs change-key zurückzuführen sind. Aber es bleibt eine Custom Lösung und man muss sich klar sein was man tut.

 

[Stefan33]

@selbitschka
Vielen Dank für die ausführliche Erklärung!

Behebt deine Vorgehensweise auch das Problem mit dem Prüfsummenfehler bei Snapshots?

Ich bin leider zu wenig in der Materie um alles zu verstehen, aber es scheint zumindest eine gangbare Lösung mit ZFS-Verschlüsselung zu geben.
Auch will ich mich bemühen zu verstehen, was ich nun genau tun muss, damit es für mich funktioniert.

Zunächst noch ein paar Verständnisfragen:

1. Kann man die Verschlüsselung für ein Dataset im Nachgang aktivieren, oder muss es bei der Erstellung schon aktiviert sein, bevor Daten darauf abgelegt werden, damit diese verschlüsselt sind?

2. Diese Problematik mit der ZFS-Verschlüsselung, tritt dies nur auf, wenn ich ein Cluster benutze und die Maschinen darauf replizieren lasse, oder besteht die auch beim normalen Backup auf den PBS, weil das Backup auch den selben Befehl wie bei der Replizierung nutzt?

3. Wenn ich mein Dataset mit meiner VM mit ZFS verschlüsselt habe, ist dann das Backup auf den PBS auch verschlüsselt, oder muss ich hier trotzdem die Backup-Verschlüsselung im PVE aktivieren?

@fabian
Vielen Dank für deinen Hinweis auf diesen Bug: https://github.com/openzfs/zfs/issues/11679
Leider bin ich beim Versuch zu verstehen, was hier genau das Problem ist, gescheitert.

Wird dieses Problem mit dem Workaround von @selbitschka ebenfalls umgangen, oder ist das eine andere Baustelle?

Tut mir leid, wenn ich euch Profis mit Laienfragen nerve...

 

[selbitschka]

Behebt deine Vorgehensweise auch das Problem mit dem Prüfsummenfehler bei Snapshots?

Dieser Fehler ist mir nicht bekannt hier müsste bitte @fabian was dazu sagen.

1. Kann man die Verschlüsselung für ein Dataset im Nachgang aktivieren, oder muss es bei der Erstellung schon aktiviert sein, bevor Daten darauf abgelegt werden, damit diese verschlüsselt sind?

Kannst du aber davor geschriebene Daten werden nicht verschlüsselt, somit sinnlos. Erstelle dir einfach 2 Datasets für VMs eines mit und eines ohne Verschlüsselung, dann kannst du ohne beginnen und wenn es dich freute eine Disk mal auf das verschlüsselte Volume verschieben.

2. Diese Problematik mit der ZFS-Verschlüsselung, tritt dies nur auf, wenn ich ein Cluster benutze und die Maschinen darauf replizieren lasse, oder besteht die auch beim normalen Backup auf den PBS, weil das Backup auch den selben Befehl wie bei der Replizierung nutzt?

Das Problem besteht vorallem bei der Replikation/Migration in einem Cluster. Wie das mit PBS ZFS backups ist kann ich leder nicht sagen, da ich hier eine eigene Lösung verwende (https://github.com/selbitschka/zfs-backup-pve).

3. Wenn ich mein Dataset mit meiner VM mit ZFS verschlüsselt habe, ist dann das Backup auf den PBS auch verschlüsselt, oder muss ich hier trotzdem die Backup-Verschlüsselung im PVE aktivieren?

Kommt darauf an wie die Daten per zfs gesendet werden. Wenn der Parameter (-w) verwendet wird ja sonst nein.

@fabian
Vielen Dank für deinen Hinweis auf diesen Bug: https://github.com/openzfs/zfs/issues/11679
Leider bin ich beim Versuch zu verstehen, was hier genau das Problem ist, gescheitert.

Wird dieses Problem mit dem Workaround von @selbitschka ebenfalls umgangen, oder ist das eine andere Baustelle?

Die hier beschrieben Probleme sind verschiedene und haben fast immer damit zu tun das du in ein verschlüsseltes Datenset empfängst. Hier bleibt die Empfängerseite hängen. Wenn du jedoch einzelne Datenset die bereits verschlüsselt sind sendest muss oder sollte das Ziel selbst nicht verschlüsselt sein, da die Snapshot es ja schon sind. Dann sollte dieser Bug nicht auftreten. Ich hatte diesen in den letzten 2,5 Jahren in dem ich ZFS verschlüsselte Snapshots verwende jedenfalls noch nie gehabt.

 

[fabian]

@selbitschka
Vielen Dank für die ausführliche Erklärung!

Behebt deine Vorgehensweise auch das Problem mit dem Prüfsummenfehler bei Snapshots?

Ich bin leider zu wenig in der Materie um alles zu verstehen, aber es scheint zumindest eine gangbare Lösung mit ZFS-Verschlüsselung zu geben.
Auch will ich mich bemühen zu verstehen, was ich nun genau tun muss, damit es für mich funktioniert.

ich weiß nicht welche Bugs genau in welchen Konstellationen triggern, da ich aufgrund der Fülle an Problemen die seit dem Einführen der Native Encryption bekannt geworden sind meine Finger davon gelassen habe ich verfolge den ZFS Bugtracker mit, und von der Seite habe ich nicht den Eindruck dass hier schon ein "Ende" in Sicht ist, zumal der Hauptentwickler und -sponsor des Encryption Features nicht mehr wirklich aktiv ist.

Zunächst noch ein paar Verständnisfragen:

1. Kann man die Verschlüsselung für ein Dataset im Nachgang aktivieren, oder muss es bei der Erstellung schon aktiviert sein, bevor Daten darauf abgelegt werden, damit diese verschlüsselt sind?

muss beim Erstellen des Datasets (explizit, oder über inherit) aktiviert werden.

2. Diese Problematik mit der ZFS-Verschlüsselung, tritt dies nur auf, wenn ich ein Cluster benutze und die Maschinen darauf replizieren lasse, oder besteht die auch beim normalen Backup auf den PBS, weil das Backup auch den selben Befehl wie bei der Replizierung nutzt?

die meisten Probleme treten meines Wissens nach im Zusammenhang mit send/recv (in PVE: replication, storage migration, offline migration von volumes) und Snapshots (in PVE: Gast snapshots, "snapshot" mode container backup, Replication, storage migration) auf. PBS backups verwenden nur bei Containern im modus "snapshot" Storage Snapshots, andere Modi oder VM Backups verwenden keine speziellen Storage Features, also auch keine von ZFS.

3. Wenn ich mein Dataset mit meiner VM mit ZFS verschlüsselt habe, ist dann das Backup auf den PBS auch verschlüsselt, oder muss ich hier trotzdem die Backup-Verschlüsselung im PVE aktivieren?

wenn du ZFS auf Hypervisor Ebene verschlüsselst, muss das entsprechende Dataset ja entschlüsselt sein damit die VM drauf zugreifen kann. Das Backup passiert im Qemu-Prozess, d.h. im Klartext (außer PBS + PBS-Encryption). wie weiter oben schon erwähnt - nur wenn du *in der VM drinnen* verschlüsselst, würde ein Backup das von PVE gemacht wird verschlüsselte Daten lesen und sichern.

@fabian
Vielen Dank für deinen Hinweis auf diesen Bug: https://github.com/openzfs/zfs/issues/11679
Leider bin ich beim Versuch zu verstehen, was hier genau das Problem ist, gescheitert.

Wird dieses Problem mit dem Workaround von @selbitschka ebenfalls umgangen, oder ist das eine andere Baustelle?

Tut mir leid, wenn ich euch Profis mit Laienfragen nerve...

s.o.

 

[Stefan33]

Vielen Dank für die tolle Hilfe hier!

Ich will es nun mit ZFS-Verschlüsselung versuchen, verzichte jedoch erst einmal auf die Cluster-Funktion. Die Cluster-Funktion "ersetzte" ich durch die schnelle Rücksicherungsmöglichkeit vom PBS (Live-Migration).
Dadurch, dass die Backups auf dem PBS keinen "ZFS-Verschlüsselungs-Balast" mitnehmen, ist die Rücksicherung unproblematisch, was das Thema betrifft.

Wenn ich die Anleitung von @selbitschka irgenwann verstanden habe, will ich es mit der Migration versuchen. Aber da bin ich schon daran gescheitert, dass es den beschrieben Ordner bei mir gar nicht gibt.

Vielen Dank für die Unterstützung, jetzt gehe ich mal an die Umsetzung...