ZFS Native Encryption - Proxmox Installer zur Laufzeit anpassen?

[fpausp]

Würde gerne Proxmox auf verschlüsseltem ZFS installieren...

1. Hab diese Methode gefunden aber noch nicht getestet: Simple guide for fulldisk encryption with Proxmox and ZFS native encryption

2. Und diese mit Ubuntu erfolgreich getestet wo gleich beim Installieren eingegriffen wird: Encrypting ZFS on Ubuntu 20.04

Ich frage mich ob man (2.) mit dem Proxmox Installer irgendwie hinbekommen könnte?

 

[dietmar]

Please open a feature request at https://bugzilla.proxmox.com

 

[fpausp]

Please open a feature request at https://bugzilla.proxmox.com

OK, erledigt: Native ZFS encryption during the Proxmox Installation

 

[janosch1337]

hey,

@fpausp hast du was davon getestet? vielleicht kannst du ja bisschen infos geben

lg

 

[fpausp]

@fpausp hast du was davon getestet?

Noch nicht, steht aber auf der ToDo Liste...

 

[fpausp]

hey,

@fpausp hast du was davon getestet? vielleicht kannst du ja bisschen infos geben

lg

Hallo, habs grad probiert.

#
# Install Proxmox on ZFS-Filesystem
#

# Use UEFI BIOS !!!
The commands for ZFS-Encryption need UEFI enabled.

# Install from Proxmox CD/ISO:
Install Proxmox CD/ISO and use ZFS Filesystem.

# Reboot
Reboot after installation to check everything works.

# Shutdown
Schutdown after first reboot.



#
# Boot into Livesystem Proxmox CD/ISO
#

Boot Proxmox ISO with debug mode and then > Strg+D > Strg+D

# copy encprox.sh from another server to the livesystem:
scp <my-server-ip>:/root/encprox.sh .


--------------------------------content of encprox.sh --------------------------------------
# Import the old
zpool import -f rpool

# Make a snapshot of the current one
zfs snapshot -r rpool/ROOT@copy

# Send the snapshot to a temporary root
zfs send -R rpool/ROOT@copy | zfs receive rpool/copyroot

# Destroy the old unencrypted root
zfs destroy -r rpool/ROOT

# Create a new zfs root, with encryption turned on
# OR -o encryption=aes-256-gcm - aes-256-ccm vs aes-256-gcm
zfs create -o encryption=on -o keyformat=passphrase rpool/ROOT

# Copy the files from the copy to the new encrypted zfs root
zfs send -R rpool/copyroot/pve-1@copy | zfs receive -o encryption=on rpool/ROOT/pve-1

# Set the Mountpoint
zfs set mountpoint=/ rpool/ROOT/pve-1

# Export the pool again, so you can boot from it
zpool export rpool
--------------------------------content of encprox.sh --------------------------------------


# start the encryption script
sh encprox.sh

... use a strong password if asked.

# reboot with:
Strg+D

# Change the bood order to ssd/hdd:
...

# Boot into the new encrypted Proxmox :)

Frage an die Experten ob das so passt und was man da noch aufräumen könnte ?

 

[jhamfler]

Ich habe zwei Verbesserungsvorschläge:
1. zfs destroy -r rpool/copyroot
Bei mir wurde rpool/copyroot anstatt rpool/ROOT gemountet (df -h)

2. Nur / zu verschlüsseln reicht mMn nicht. Man sollte noch das hier tun (nur bei einer frischen Installation ohne VMs):

export KEYPATH=/root/zfs-data-key
dd if=/dev/random bs=32 count=1 of=$KEYPATH
chmod 440 $KEYPATH
zfs destroy rpool/data # wenn nicht leer, dann die Methode wie bei rpool/ROOT
zfs create -o encryption=on -o checksum=sha512 -o compress=zstd -o keyformat=raw -o keylocation=file://$KEYPATH rpool/data
zfs load-key -L file:///root/zfs-data-key rpool/data
zfs get encryption rpool/data

Nach einem Neustart sollte rpool/data nicht eingebunden sein. Um das zu beheben empfehle ich eine Datei unter /etc/systemd/system/data-mount.service anzulegen:

[Unit]
Description=Mount ZFS filesystems
Documentation=man:zfs(8)
DefaultDependencies=no
After=systemd-udev-settle.service
After=zfs-import.target
After=zfs-mount.target
After=systemd-remount-fs.service
ConditionPathIsDirectory=/sys/module/zfs

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/zfs load-key -L file:///root/zfs-data-key rpool/data

[Install]
WantedBy=zfs.target

Und dann noch:

systemctl enable data-mount.service
systemctl start data-mount.service
sleep 10
df -h # prüfen

Nach einem Neustart sollte dann auch data vorhanden sein.

Die ganzen zusätzlichen Schritte finde ich besser, weil man mit einem Passwort wie vorher / entschlüsselt. In / bzw. /root/ (was ja auch in / liegt) ist dann der Schlüssel um data zu entschlüsseln. Damit muss man im Zweifel nicht 2x ein Passwort eingeben für Proxmox und den VM-Speicher und die VMs werden auch verschlüsselt gespeichert.

Über Kritik würde ich mich freuen, da ich das gerade erst ausprobiert habe und es vielleicht noch bessere Möglichkeiten gibt.

 

[Dunuin]

2. Nur / zu verschlüsseln reicht mMn nicht. Man sollte noch das hier tun (nur bei einer frischen Installation ohne VMs):

export KEYPATH=/root/zfs-data-key
dd if=/dev/random bs=32 count=1 of=$KEYPATH
chmod 440 $KEYPATH
zfs destroy rpool/data # wenn nicht leer, dann die Methode wie bei rpool/ROOT
zfs create -o encryption=on -o checksum=sha512 -o compress=zstd -o keyformat=raw -o keylocation=file://$KEYPATH rpool/data
zfs load-key -L file:///root/zfs-data-key rpool/data
zfs get encryption rpool/data

Nach einem Neustart sollte rpool/data nicht eingebunden sein. Um das zu beheben empfehle ich eine Datei unter /etc/systemd/system/data-mount.service anzulegen:

[Unit]
Description=Mount ZFS filesystems
Documentation=man:zfs(8)
DefaultDependencies=no
After=systemd-udev-settle.service
After=zfs-import.target
After=zfs-mount.target
After=systemd-remount-fs.service
ConditionPathIsDirectory=/sys/module/zfs

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/zfs load-key -L file:///root/zfs-data-key rpool/data

[Install]
WantedBy=zfs.target

Und dann noch:

systemctl enable data-mount.service
systemctl start data-mount.service
sleep 10
df -h # prüfen

Nach einem Neustart sollte dann auch data vorhanden sein.

Die ganzen zusätzlichen Schritte finde ich besser, weil man mit einem Passwort wie vorher / entschlüsselt. In / bzw. /root/ (was ja auch in / liegt) ist dann der Schlüssel um data zu entschlüsseln. Damit muss man im Zweifel nicht 2x ein Passwort eingeben für Proxmox und den VM-Speicher und die VMs werden auch verschlüsselt gespeichert.

Über Kritik würde ich mich freuen, da ich das gerade erst ausprobiert habe und es vielleicht noch bessere Möglichkeiten gibt.

Ja, mache ich hier in etwa auch so.
Außerdem nicht vergessen vor der PVE installation die komplette SSD per per "secure erase" Befehl einmal komplett auf Werkszustand zurückzusetzen. Sonst gibt es keine Chance da je alle unverschlüsselten Daten komplett von der SSD zu bekommen (die SSD hat ja auch eine unzugängliche Spare Area, die sich nicht gezielt überschreiben/löschen lässt). Folglich bei der PVE Installation auch keine echten Passwörter und Co verwenden, da die dann später immer noch auf der SSD rumfliegen könnten. Lieber erst dem Root-User ein richtiges Passwort geben, wenn man das Root-Dateisystem bereits verschlüsselt hat.

Was ich mich nur Frage ist, was man am besten wegen Swap macht. Swap darf ja nicht auf ZFS drauf und auch nicht auf mdadm raid. Ich hätte aber trotzdem gerne eine gespiegelte verschlüsselte Swap-Partition.

 

[mr44er]

Außerdem nicht vergessen vor der PVE installation die komplette SSD per per "secure erase" Befehl einmal komplett auf Werkszustand zurückzusetzen.

Einmal das und ich würde noch ein blkdiscard -f -v /dev/sda vor der Installation machen sowie der SSD dann ~60 Sekunden Zeit geben, sich zu berappeln. Das ist entweder bei knoppix dabei oder wenn man mit gebootetem Proxmoxinstaller kurz mit STRG+ALT+F2 auf die Konsole wechselt.

Swap darf ja nicht auf ZFS drauf

Korrekt, das geht unbefriedigend schief.

Was ich mich nur Frage ist, was man am besten wegen Swap macht.

Im Proxmoxinstaller unter advanced die Partition um die Größe deiner gewünschten swap-Partition am Ende verkleinern.
Danach:

fdisk /dev/sda -> 'n' (4. new)
enter durchdrücken
t (4) -> 'swap'
'w'
fdisk -l
mkswap /dev/sda4

Hier die UUID merken und die /etc/fstab anpassen:
UUID=blablubb-xxx-xxx-xxx none swap defaults 0 0

Einmal rebooten und es sollte klappen.

Optional noch die swappiness anpassen in /etc/sysctl.conf
vm.swappiness=100
0 nimmt man eigentlich für Server, weil man jede Art delay vermeiden möchte, aber ich hatte mangels RAM schon den Fall, dass vms dann erst gar nicht starten. 100 hat das dann behoben.

0=Vermeide swap, bis es nicht mehr geht
100=Nimm swap sofort und immer

Ist jetzt zwar nicht gespiegelt, aber ich verstehe auch nicht, was gespiegelter swap bringen soll.

 

[Dunuin]

Ist jetzt zwar nicht gespiegelt, aber ich verstehe auch nicht, was gespiegelter swap bringen soll.

Bei mir sind immer alle Disks redundant, dass da alles ohne Downtime und ohne Datenverlust weiterläuft, wenn da mal eine Disk ausfällt (und das tun sie ständig, alleine dieses Jahr 3 System-SSDs). Wäre mein Swap nicht redundant und dann fällt die Disk mit dem Swap aus, dann stürzt der ganze Server ab, da ja die benötigten Daten vom RAM auf die Disk ausgelagert wurden. Gespiegelter Swap auf Software Raid1 würde das natürlich vermeiden.
Habe bei der PVE Installation auch immer entsprechend Platz für Swappartitionen unpartitioniert gelassen, nur habe ich noch nichts sinnvolles gefunden, wie ich da die Swap-Partitionen spiegeln könnte. Läuft bei einem Server derzeit noch als mdadm raid1, aber das soll man ja eigentlich auch nicht (siehe hier). Dem anderen Server habe ich erst gar keinen Swap verpasst. Weil ist da kein Swap, dann schmiert der Server auch nicht beim Diskausfall ab...dafür dann aber wenn der RAM mal vollläuft.

Also bisher alle Optionen sehr unbefriedigend.

 

[mr44er]

Ok, das hatte ich nicht auf dem Schirm. Hier sind alle Installationen auf single disks, da ist es eh egal.
Aber ja, mdadm scheint da noch der beste Ansatz zu sein. Man müsste mal wissen, was tatsächlich passiert, wenn eine Platte damit stirbt, denn die Posts dazu sind ja auch schon wieder was älter.

 

[jhamfler]

Wenn du in das Problem läufst, dass du zu wenig RAM hast und dein Speicher deswegen viel schreiben muss und der dadurch ausfällt, du das aber brauchst, empfehle ich dir mal eine dieser >=64GB Optane m.2 zu kaufen. Angeblich sind die wesentlich robuster als normale SSDs, da die eine andere Technologie verwenden. Außerdem liegen die von der Zugriffszeit her ungefähr zwischen SSDs und RAM. Dann brauchst du keinen Spiegel und hast schnelleren Swap.

 

[Dunuin]

Wenn du in das Problem läufst, dass du zu wenig RAM hast und dein Speicher deswegen viel schreiben muss und der dadurch ausfällt, du das aber brauchst, empfehle ich dir mal eine dieser >=64GB Optane m.2 zu kaufen. Angeblich sind die wesentlich robuster als normale SSDs, da die eine andere Technologie verwenden. Außerdem liegen die von der Zugriffszeit her ungefähr zwischen SSDs und RAM. Dann brauchst du keinen Spiegel und hast schnelleren Swap.

Ja, für alles andere habe ich hier auch sehr haltbare Enterprise SSDs. Als System Disks habe ich hier aber zum Großteil noch 120GB TLC Consumer SSDs am laufen und die schreibt ZFS regelmäßig kaputt, obwohl die rein für das System benutzt werden. Die müsste ich irgendwann noch mal gegen Enterprise SSDs austauschen, aber da fehlte gerade das Budget für und der GEbrauchtmarkt ist da für meine bevorzugten Modelle auch ziemlich leergefegt. Da taucht vielleicht jedes halbe Jahr mal eine SSD auf eBay auf. Sind jetzt aktuell noch 4 Consumer + 4 Enterprise SSDs als System Disks und 13 Enterprise SSDs für Daten/Gäste.

Beim RAM gucke ich schon, dass ich da kein RAM-Overprovisioning betreibe und nicht mehr Gäste starte, als mir RAM zur Verfügung steht. Und Swappiness ist überall auf 0 gesetzt, dass da im Normalfall auch garnicht erst geswappt werden muss. Würde es trotzdem schöner finden, als Sicherheit etwas Swap zu haben, dass da der Server garnicht erst abstürzen kann, wenn ich doch ausversehen mal zu viele Gäste starte oder ähnliches.