I've been playing around with LUKSv1 encrypted NFS volumes today after I was asked if Ia255a25da081e7ac42b4caba7a4cbd8d76ac5848 would also extend encrypted NFS volumes and have stumbled across several major issues with the recently landed implementation.
At present when creating an encrypted LUKSv1 NFS volume we create a LUKSv1 encrypted QCOW2 file:
This is fine however we then go on to attach the os-brick provided cryptsetup encryptors that attempt to open the device as if it were a plain LUKSv1 encrypted device:
Note that the file now reports a format of RAW and an incorrect virtual size. This breaks volume attachment to running instances *and* volume creation from images, both of which appear untested in Tempest at the moment for LUKSv1 volumes.
I've been playing around with LUKSv1 encrypted NFS volumes today after I was asked if Ia255a25da081e7 ac42b4caba7a4cb d8d76ac5848 would also extend encrypted NFS volumes and have stumbled across several major issues with the recently landed implementation.
At present when creating an encrypted LUKSv1 NFS volume we create a LUKSv1 encrypted QCOW2 file:
Jul 23 09:48:19 localhost. localdomain cinder- volume[ 179023] : DEBUG oslo_concurrenc y.processutils [None req-378df225- 2051-4dbf- ad69-0a6e1b020c 38 admin None] CMD "sudo cinder-rootwrap /etc/cinder/ rootwrap. conf qemu-img create -f qcow2 -o encrypt. format= luks,encrypt. key-secret= *** --object secret, id=sec1, format= raw,file= /opt/stack/ data/cinder/ conversion/ tmpjar1igr5 /opt/stack/ data/cinder/ mnt/896fb15da60 36b68a917322e72 ebfe57/ volume- 9a9d8993- 5594-4618- a259-78fa0f9206 33 1073741824" returned: 0 in 5.251s {{(pid=179042) execute /usr/local/ lib/python3. 7/site- packages/ oslo_concurrenc y/processutils. py:416} }
This is fine however we then go on to attach the os-brick provided cryptsetup encryptors that attempt to open the device as if it were a plain LUKSv1 encrypted device:
Jul 23 09:48:21 localhost. localdomain cinder- volume[ 179023] : Command: cryptsetup luksOpen --key-file=- /opt/stack/ data/cinder/ mnt/896fb15da60 36b68a917322e72 ebfe57/ volume- 9a9d8993- 5594-4618- a259-78fa0f9206 33 crypt-volume- 9a9d8993- 5594-4618- a259-78fa0f9206 33 localdomain cinder- volume[ 179023] : Exit code: 1
Jul 23 09:48:21 localhost.
As the file is actually QCOW2 this fails and the encryptors then reformat the file as a plain LUKSv1 file:
Jul 23 09:48:21 localhost. localdomain cinder- volume[ 179023] : INFO os_brick. encryptors. luks [None req-378df225- 2051-4dbf- ad69-0a6e1b020c 38 admin None] /opt/stack/ data/cinder/ mnt/896fb15da60 36b68a917322e72 ebfe57/ volume- 9a9d8993- 5594-4618- a259-78fa0f9206 33 is not a valid LUKS device; formatting device for first use localdomain cinder- volume[ 179023] : DEBUG oslo_concurrenc y.processutils [-] CMD "cryptsetup --batch-mode luksFormat --type luks1 --key-file=- --cipher aes-xts-plain64 --key-size 256 /opt/stack/ data/cinder/ mnt/896fb15da60 36b68a917322e72 ebfe57/ volume- 9a9d8993- 5594-4618- a259-78fa0f9206 33" returned: 0 in 4.256s {{(pid=237616) execute /usr/local/ lib/python3. 7/site- packages/ oslo_concurrenc y/processutils> localdomain cinder- volume[ 179023] : DEBUG oslo.privsep.daemon [-] privsep: reply[139834412 181648] : (4, ('', '')) {{(pid=237616) _call_back /usr/local/ lib/python3. 7/site- packages/ oslo_privsep/ daemon. py:475} }
[..]
Jul 23 09:48:25 localhost.
Jul 23 09:48:25 localhost.
At this point the volume is no longer QCOW2 as we've basically done the following:
# qemu-img create -f qcow2 -o encrypt. format= luks,encrypt. key-secret= sec1 --object secret, id=sec1, format= raw,data= foo test.img 100M key-secret= sec1 cluster_size=65536 lazy_refcounts=off refcount_bits=16
Formatting 'test.img', fmt=qcow2 size=104857600 encrypt.format=luks encrypt.
# qemu-img info test.img 0c52-462e- a4e7-c8b3f19b89 6b
active: true
iters: 1881118
stripes: 4000
active: false
active: false
active: false
active: false
active: false
active: false
active: false
image: test.img
file format: qcow2
virtual size: 100 MiB (104857600 bytes)
disk size: 480 KiB
encrypted: yes
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
encrypt:
ivgen alg: plain64
hash alg: sha256
cipher alg: aes-256
uuid: d0363765-
format: luks
cipher mode: xts
slots:
[0]:
key offset: 4096
[1]:
key offset: 262144
[2]:
key offset: 520192
[3]:
key offset: 778240
[4]:
key offset: 1036288
[5]:
key offset: 1294336
[6]:
key offset: 1552384
[7]:
key offset: 1810432
payload offset: 2068480
master key iters: 474321
corrupt: false
# cryptsetup --batch-mode luksFormat --type luks1 --key-file=- --cipher aes-xts-plain64 --key-size 256 test.img ea2f-45ca- acde-be4512ba7b 8a
stripes: 4000
Enter passphrase for test.img:
# qemu-img info test.img
image: test.img
file format: luks
virtual size: 256 KiB (262144 bytes)
disk size: 2.03 MiB
encrypted: yes
Format specific information:
ivgen alg: plain64
hash alg: sha256
cipher alg: aes-128
uuid: d325d8e2-
cipher mode: xts
slots:
[0]:
active: true
iters: 4009850
key offset: 4096
[1]:
active: false
key offset: 135168
[2]:
active: false
key offset: 266240
[3]:
active: false
key offset: 397312
[4]:
active: false
key offset: 528384
[5]:
active: false
key offset: 659456
[6]:
active: false
key offset: 790528
[7]:
active: false
key offset: 921600
payload offset: 2097152
master key iters: 250137
Note that the file now reports a format of RAW and an incorrect virtual size. This breaks volume attachment to running instances *and* volume creation from images, both of which appear untested in Tempest at the moment for LUKSv1 volumes.