.. _howto.encryption: Disk Encryption *************** Introduction ============ The OpenSVC agent can manage encrypted block devices. This section describes how to deploy a simple filesystem over encrypted block device stack. Prerequisites ============= This feature requires: * OpenSVC agent version 2.1-1405 minimum * cryptsetup binary (LUKS implementation) Configuration ============= Loopback device --------------- Service configuration ^^^^^^^^^^^^^^^^^^^^^ We can use a loop device to demonstrate the encrypted datas. First, we build the service template file:: # cat > /tmp/loopback.conf <<-EOF [DEFAULT] id = e60306f6-e429-4a02-bd8f-a537a918a217 [disk#0] type = loop file = /opt/{fqdn}.img size = 1G [disk#1] type = crypt dev = {disk#0.exposed_devs[0]} name = {fqdn}-crypt [fs#0] type = ext4 dev = {disk#1.exposed_devs[0]} mnt = /srv/{svcname} EOF Service creation ^^^^^^^^^^^^^^^^ Then, we can deploy the ``loopcrypt`` service, in the ``demo`` namespace:: # om demo/svc/loopcrypt create --config=/tmp/loopback.conf create demo/svc/loopcrypt The service is created, but not provisioned:: # om demo/svc/loopcrypt print status -r demo/svc/loopcrypt down `- instances `- demo1 down not provisioned, idle |- disk#0 .....P.. down loop /opt/loopcrypt.demo.svc.default.img |- disk#1 .....P.. down crypt /dev/mapper/loopcrypt.demo.svc.default-crypt `- fs#0 .....P.. down ext4 /dev/mapper/loopcrypt.demo.svc.default-crypt@/srv/loopcrypt Service start ^^^^^^^^^^^^^ We first have to provision the service, which will build and start ressources:: # om demo/svc/loopcrypt provision --wait @ n:demo1 o:demo/svc/loopcrypt sc:n demo/svc/loopcrypt defer target state set to provisioned The new service state is now provisioned, and all resources are up:: # om demo/svc/loopcrypt print status -r demo/svc/loopcrypt up `- instances `- demo1 up idle, started |- disk#0 ........ up loop /opt/loopcrypt.demo.svc.default.img |- disk#1 ........ up crypt /dev/mapper/loopcrypt.demo.svc.default-crypt `- fs#0 ........ up ext4 /dev/mapper/loopcrypt.demo.svc.default-crypt@/srv/loopcrypt # om demo/svc/loopcrypt print devs demo/svc/loopcrypt |- disk#0 (disk.loop) | |- base | | `- /dev/sda | `- exposed | `- /dev/loop1 `- disk#1 (disk.crypt) |- base | `- /dev/sda |- sub | `- /dev/loop1 `- exposed `- /dev/mapper/loopcrypt.demo.svc.default-crypt # losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 0 0 /opt/loopcrypt.demo.svc.default.img 0 512 # df -h /srv/loopcrypt Filesystem Size Used Avail Use% Mounted on /dev/mapper/loopcrypt.demo.svc.default-crypt 977M 2.5M 908M 1% /srv/loopcrypt .. note:: LUKS encryption requires space to store metadatas (16kB) and keyslots (16MB), that's why the usable space in the ``df`` is less than the ``1GB`` size requested initially. While running provision actions, the agent did the following tasks in the background: - create the ``/opt/loopcrypt.demo.svc.default.img`` file with a 1GB size - configure a loop device ``/dev/loop1`` over ``/opt/loopcrypt.demo.svc.default.img`` file - create an opensvc secret object ``demo/sec/loopcrypt`` to store the passphrase (if it did not exist yet) - generate a random passphrase and store it in the ``demo/sec/loopcrypt`` object, associated with key ``disk_1_crypt_passphrase`` (change the passphrase if it already existed, see the ``manage_passphrase`` keyword documentation for more information about this policy) - run a ``cryptsetup luksFormat`` command to encrypt the loop device contents - run a ``cryptsetup luksOpen`` command to expose ``/dev/mapper/loopcrypt.demo.svc.default-crypt`` which is the unencrypted block device to store data - create a ``/srv/loopcrypt`` mountpoint - run a mkfs.ext4 on the ``/dev/mapper/loopcrypt.demo.svc.default-crypt`` block device - mount the ``/dev/mapper/loopcrypt.demo.svc.default-crypt`` block device on the ``/srv/loopcrypt`` mountpoint We can see that the secret object has been created by the agent:: # om demo/sec/loopcrypt keys disk_1_crypt_passphrase # om demo/sec/loopcrypt decode --key disk_1_crypt_passphrase >#pQ$R)|n%PBORIXhU]A;pM[4q|{o1H!z|Z;fkrvP[(;xueG[qs(g%_p^cn>TP!W/C /tmp/sancrypt.conf <<-EOF [DEFAULT] id = 2d683ea4-5006-4e82-aae1-169d10d1f34a [disk#1] type = crypt dev = /dev/mapper/36589cfc000000b4f42b70859f9e9dbee name = {fqdn}-crypt [fs#0] type = ext4 dev = {disk#1.exposed_devs[0]} mnt = /srv/{svcname} EOF Service creation ^^^^^^^^^^^^^^^^ Then, we can deploy the ``sancrypt`` service, in the ``demo`` namespace:: # om demo/svc/sancrypt create --config=/tmp/sancrypt.conf create demo/svc/sancrypt Service start ^^^^^^^^^^^^^ We first have to provision the service, which will build and start ressources:: # om demo/svc/sancrypt provision --wait @ n:demo1 o:demo/svc/sancrypt sc:n demo/svc/sancrypt defer target state set to provisioned The new service state is now provisioned, and all resources are up:: # om demo/svc/sancrypt print status -r demo/svc/sancrypt up `- instances `- demo1 up idle, started |- disk#1 ........ up crypt /dev/mapper/sancrypt.demo.svc.default-crypt `- fs#0 ........ up ext4 /dev/mapper/sancrypt.demo.svc.default-crypt@/srv/sancrypt # om demo/svc/sancrypt print devs demo/svc/sancrypt |- fs#0 (fs) | |- base | | |- /dev/dm-12 | | `- /dev/sdx | `- sub | |- /dev/sdk | `- /dev/sdx `- disk#1 (disk.crypt) |- base | `- /dev/dm-12 |- sub | `- /dev/mapper/36589cfc000000b4f42b70859f9e9dbee `- exposed `- /dev/mapper/sancrypt.demo.svc.default-crypt # df -h /srv/sancrypt Filesystem Size Used Avail Use% Mounted on /dev/mapper/sancrypt.demo.svc.default-crypt 977M 2.5M 908M 1% /srv/sancrypt We can see that the secret object has been created by the agent:: # om demo/sec/sancrypt keys disk_1_crypt_passphrase # om demo/sec/sancrypt decode --key disk_1_crypt_passphrase Rc)ovE#k|tw?E,6Y@L}f+Vg,KGzi*]{EU,YNot5rJRbN^2hln`~-]~7LPAKb8;4zAM,g7:X?[fLXa,lCQN[yF%zz8jocb@7^-Z~[WR^5fA/sys/fs/cgroup/freezer/opensvc.slice/demo.slice/loopcrypt.slice/cgroup.clone_children no task to kill The ``cryptsetup luksClose`` definitely close the unencrypted block device. To reopen it, the sysadmin would have to restore the passphrase in the secret object key, and start the service. Unprovision/Purge ================= .. warning:: Be aware that running ``unprovision`` or ``purge`` service actions will lead to **data loss**