Open Stack

On 31-05-17 20:06:01, Farr, Kaitlin M. wrote:
>> 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?
> 
>     It sounds like you're thinking that using a key manager object with the type
> "passphrase" is closer to how the encryptors are using the bytes than using the
> "symmetric key" type, but if you switch over to using passphrases,
> where are you going to generate the random bytes?  Would you prefer the
> user to input their own passphrase?  The benefit of continuing to use symmetric
> keys as "passphrases" is that the key manager can randomly generate the bytes.
> Key generation is a standard feature of key managers, but password generation
> Is not.

Thanks for responding Kaitlin, I'd be happy to have the key manager
generate a random passphrase of a given length as defined by the volume
encryption type. I don't think we would want any user input here as
ultimately the encryption is transparent to them.

> On a side note, I thought the latest QEMU encryption feature was supposed to
> have support for passing in key material directly to the encryptors?  Perhaps
> this is not true and I am misremembering.

That isn't the case, with the native LUKS support in QEMU we can now
skip the use of the front-end encryptors entirely. We simply provide the
passphrase via a libvirt secret associated with the volume that is then
passed to QEMU in a secure fashion [1] to unlock the LUKS volume. 

[1] https://www.berrange.com/posts/2016/04/01/improving-qemu-security-part-3-securely-passing-in-credentials/

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76