TrueCrypt container as storage for XenServer virtual machines
There was a task to implement encrypted containers for a virtual machine on XenServer, and in addition to encrypt them using TrueCrypt. Not finding any useful information on the topic on the network, I decided to share a note on this issue. At the moment, the solution was put into operation, it works and does not cough.
There are many answers, but the most common is that there is private information that needs to be encrypted from unwanted eyes and persons in the event of physical violence against the server.
Yeah why not. But in my case, I would have to encrypt about 20 machines, and in the case of a reboot, I would have to connect all 20 containers, which is not very convenient. Therefore, we will immediately encrypt the disk and deploy all virtual machines to it.
First of all, we need an installed XenServer . On the Internet, there are a lot of manuals for this process, so I’ll skip it.
')
We need a place on the disk where the hypervisor is installed or a separate disk. I think that it’s better for such things to use a separate disk or even a raid array, because if the information is so private that it needs to be encrypted, then its loss will surely please anyone.
The procedure for preparing the disc is standard for linux systems and experienced users will not be a hassle, but just in case I remind you:
Mark the disk in:
Through mkfs.ext3 create a file system for the partition.
Add mount rules to fstab and the floor is done.
It's time to install truecrypt:
Everything is cool, but the xen'e lacks libfuse.so.2 by default. The hypervisor is managed from a virtual machine on CentOS, so for us this is not a big problem:
Now everything is prepared to create an encrypted container:
The process itself will take some time, it all depends on the disk subsystem and server capacity.
I have ~ 300Gb container created about 2 hours ...
After the container is created, we mount it into the system; we will be forwarding it to xen:
If everything is done correctly, then after running truecrypt --list we will see a list of mounted containers:
And finally, the very goal of all our preparatory actions is to forward the container to the xenserver:
uuid and default-SR can be found through xe pool-list and xe sr-list.
This is where the magic ends and, with the help of OpenXenManager or XenCenter, we can safely create new virtual machines in an encrypted container, without fear for their privacy in the event of incidents with physical assault.
Naturally, in the case of a reboot, you will have to pry the container with handles, forward it again and only then start the virtual machines, but for this, we tried, strictly speaking.
PS: The note is aimed at beginners or people who have never solved such problems.
The problem book asks - why goat accordion?
There are many answers, but the most common is that there is private information that needs to be encrypted from unwanted eyes and persons in the event of physical violence against the server.
Why not encrypt the data on a virtual machine?
Yeah why not. But in my case, I would have to encrypt about 20 machines, and in the case of a reboot, I would have to connect all 20 containers, which is not very convenient. Therefore, we will immediately encrypt the disk and deploy all virtual machines to it.
From words to deeds
First of all, we need an installed XenServer . On the Internet, there are a lot of manuals for this process, so I’ll skip it.
')
We need a place on the disk where the hypervisor is installed or a separate disk. I think that it’s better for such things to use a separate disk or even a raid array, because if the information is so private that it needs to be encrypted, then its loss will surely please anyone.
The procedure for preparing the disc is standard for linux systems and experienced users will not be a hassle, but just in case I remind you:
Mark the disk in:
#: fdisk /dev/sdx Through mkfs.ext3 create a file system for the partition.
#: mkfs.ext3 /dev/sdx1 Add mount rules to fstab and the floor is done.
/dev/sda1 /mnt/xen ext3 errors=remount-ro 0 0 It's time to install truecrypt:
#: wget https://download.truecrypt.ch/current/truecrypt-7.1a-linux-console-x64.tar.gz #: tar -zxvf truecrypt-7.1a-linux-console-x64.tar.gz #: ./truecrypt-7.1a-setup-console-x64 Everything is cool, but the xen'e lacks libfuse.so.2 by default. The hypervisor is managed from a virtual machine on CentOS, so for us this is not a big problem:
#: yum --enablerepo=base --disablerepo=citrix install fuse-devel fuse Now everything is prepared to create an encrypted container:
#: truecrypt -c Volume type: 1) Normal 2) Hidden Select [1]: 1 Enter volume path: /mnt/xen/dts Enter volume size (sizeK/size[M]/sizeG): 290G Encryption algorithm: 1) AES 2) Serpent 3) Twofish 4) AES-Twofish 5) AES-Twofish-Serpent 6) Serpent-AES 7) Serpent-Twofish-AES 8) Twofish-Serpent Select [1]: 1 Hash algorithm: 1) RIPEMD-160 2) SHA-512 3) Whirlpool Select [1]: 1 Filesystem: 1) None 2) FAT 3) Linux Ext2 4) Linux Ext3 5) Linux Ext4 Select [2]: 1 Enter password: Re-enter password: Enter keyfile path [none]: Please type at least 320 randomly chosen characters and then press Enter: The process itself will take some time, it all depends on the disk subsystem and server capacity.
I have ~ 300Gb container created about 2 hours ...
After the container is created, we mount it into the system; we will be forwarding it to xen:
#: truecrypt --password=*** --filesystem=none --protect-hidden=no /mnt/xen/dts If everything is done correctly, then after running truecrypt --list we will see a list of mounted containers:
1: /mnt/xen/vms1 /dev/mapper/truecrypt1 - And finally, the very goal of all our preparatory actions is to forward the container to the xenserver:
#: xe sr-create name-label=VMS shared=false device-config:device=/dev/mapper/truecrypt1 type=lvm sm-config:type=raw virtual-size=280GiB #: xe pool-param-set uuid=____ default-SR=____ uuid and default-SR can be found through xe pool-list and xe sr-list.
# xe pool-list uuid ( RO) : f33ac257-3fcf-1653-7b8f-105c83bf98d1 name-label ( RW): name-description ( RW): master ( RO): 8362a425-4bef-4712-8864-a7542ba19c80 default-SR ( RW): 950d80a8-bc98-1879-ba5f-653a01d0ced6 #: xe sr-list .... uuid ( RO) : 950d80a8-bc98-1879-ba5f-653a01d0ced6 name-label ( RW): VMS name-description ( RW): host ( RO): xenserver-luzdrjrf type ( RO): lvm content-type ( RO): This is where the magic ends and, with the help of OpenXenManager or XenCenter, we can safely create new virtual machines in an encrypted container, without fear for their privacy in the event of incidents with physical assault.
Naturally, in the case of a reboot, you will have to pry the container with handles, forward it again and only then start the virtual machines, but for this, we tried, strictly speaking.
PS: The note is aimed at beginners or people who have never solved such problems.
Source: https://habr.com/ru/post/259365/
All Articles