Hello all, I'm currently working on enabling QEMU's native LUKS support within Nova [1]. While testing this work with Barbican I noticed that Cinder is creating symmetric keys for use with encrypted volumes : https://github.com/openstack/cinder/blob/63433278a485b65ae6ed1998e7bc83933ceee167/cinder/volume/flows/api/create_volume.py#L385 https://github.com/openstack/castellan/blob/64207e303529b7fceb3b8b0f0a65f8f49b3f9b26/castellan/key_manager/barbican_key_manager.py#L206 However the only supported disk encryption formats on the front-end at present are plain (dm-crypt) and LUKS, neither of which use the supplied key to directly encrypt or decrypt data. Plain derives a fixed length master key from the provided key / passphrase and LUKS uses PBKDF2 to derive a key from the key / passphrase that unlocks a separate master key. https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions - 2.4 What is the difference between "plain" and LUKS format? I also can't find any evidence of these keys being used directly on the backend for any direct encryption of volumes within c-vol. Happy to be corrected here if there are out-of-tree drivers etc that do this. IMHO for now we are better off storing a secret passphrase in Barbican for use with these encrypted volumes, would there be any objections to this? Are there actual plans to use a symmetric key stored in Barbican to directly encrypt and decrypt volumes? This has also reminded me that the plain (dm-crypt) format really needs to be deprecated this cycle. I posted to the dev and ops ML [2] last year about this but received no feedback. Assuming there are no last minute objections I'm going to move forward with deprecating this format in os-brick this cycle. Thanks in advance, Lee [1] https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/libvirt-qemu-native-luks.html [2] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106956.html -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76