crypto luks support

[pva00]

I'going to place a proxmox node in a less secure environment, so I want to protect my physical data.

I'm familiar with luks and crypo and I want to use this on proxmox. What I do is to install a debian standard system with crypto and LVM partitions. After that I install the proxmox kernel and reboot, but this kernel doesnot recognise the encrypted partion.

If I install the same system with only LVM proxmox works fine. So can you enable crypto support in the proxmox kernel in the next version?

 

[dietmar]

I'going to place a proxmox node in a less secure environment, so I want to protect my physical data.

What kind of environment (and how does encrypted lvm protect physical data)?

 

[pva00]

It will be placed in a public data center. If crypto (AES 256) encrypte all proxmox partions (except /boot) all VMs on proxmox will be encrypted as well (VZ and KVM) with a view % of disk performance loss.

On boot you must enter a password, but with drobbear ssh you can ssh to the node and provide the crypto password.

I'dont want to recompile proxmox kernel from scratch

 

[dietmar]

It will be placed in a public data center. If crypto (AES 256) encrypte all proxmox partions (except /boot) all VMs on proxmox will be encrypted as well

And you fear that somone physically steal the hardware?

 

[jasond]

Did you install the pve kernel using apt? i.e. did you modify your debian sources.list to include the pve repository?

The reason I ask is i've installed kernels using "dpkg -i" and had similar problems to you.
What seems to happen is that the initrd is not regenerated on kernel install so you have no crypto/lvm modules at boot time.

You could try "dpkg-reconfigure pve-kernel"

hth

 

[pva00]

No, I 'm not afread for stealing the hardware. But If you can get to the hardware (disks) you can get to the data. I want to secure all the data on proxmox VE. So all VMs on proxmox and proxmox ve are encrypted. Only the boot partition isn't.


Yes, I build proxmox ve by using apt.

Thanks, I'll try dpkg-reconfigure pve-kernel ...

 

[pva00]

Nope, dpkg-reconfigure pve-kernel doesn't work.....

 

[honmanm]

I have a lenny 64 installation with encrypted root, and got the pve kernel to work by installing the pve-firmware package and then rebuilding initramfs (maybe it would also work without pve-firmware... I don't know)

update-initramfs -tuk 2.6.24-8-pve

Certainly results in a bootable system.

There are 3 warning that are a bit worrisome - Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin tg3_tso.bin, tg3.bin
Our machines have Broadcom NICs that use the tg3 driver (and in the past we have had problems with poor-quality Broadcom drivers)

When starting up with the PVE kernel, all NICs are re-detected and appear as higher-numbered entries in /etc/udev/rules.d/70-persistent-net.rules - it is necessary to edit the file, delete the old entries, and reassign eth0, eth1 etc. device names in the order you want them to be.

I'm planning to add luks-encrypted data drives with DRBD running on top of them - or perhaps the other way round.

 

[dietmar]

There are 3 warning that are a bit worrisome - Possible missing firmware /lib/firmware/tigon/tg3_tso5.bin tg3_tso.bin, tg3.bin
Our machines have Broadcom NICs that use the tg3 driver (and in the past we have had problems with poor-quality Broadcom drivers)

AFAIK the firmware is only needed for the following models:

Broadcom BCM5705 TSO firmware
Broadcom BCM5703/BCM5704 TSO firmware
Broadcom BCM5701A0 firmware

do you have any problems with the driver?

When starting up with the PVE kernel, all NICs are re-detected and appear as higher-numbered entries in /etc/udev/rules.d/70-persistent-net.rules - it is necessary to edit the file, delete the old entries, and reassign eth0, eth1 etc. device names in the order you want them to be.

that should help, yes.

 

[honmanm]

No observed problems, and the Broadcom chips in the machines I'm testing with are 5721 and 5722.

Regarding DBRD and LUKS layering, it seems that the simplest option is to interpose LUKS between the device and DRBD.

This has a few disadvantages - encryption occurs on both hosts, DRBD metadata is unnecessarily encrypted, and DRBD traffic is not encrypted.

However the encryption is then transparent to Proxmox VE and its HA functions.

The following stack would be more efficient, but is likely to be more difficult to get working reliably (especially in a primary-primary config)

LVM
LUKS
DRBD
device

One final question - is it possible for the OpenVZ containers to be backed by a DRBD volume? I assume in this case we would need to ensure that only one node is the primary. Probably use two volumes "host A's containers" and "host B's containers".

 

[tom]

...

One final question - is it possible for the OpenVZ containers to be backed by a DRBD volume? I assume in this case we would need to ensure that only one node is the primary. Probably use two volumes "host A's containers" and "host B's containers".

yes (mount /var/lib/vz on a DRBD). but this is not a supported config here.

 

[D.Thics]

if you do a seach on this forum you will find a lot of information about crypto.

 

[honmanm]

In the end we had to use the following stack

LVM
LUKS
DRBD
device

Running DRBD on top of LUKS was not satisfactory as LUKS apparently does not support some "device like" ioctls that DRBD needs, perhaps for implementation of barriers.

 

[pva00]

update-initramfs -tuk 2.6.24-8-pve

That did the trick. Thank you for the advise. Now I have a softraid encrypted proxmox server.....