On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote:
Or just the raw text in a file. Too bad we couldn't link to the
secret
driver file directly...
BTW the real for never directly pointing qemu/qemu-img at the files
maintained by the secret driver itself is that we don't want to bake
in an assumption that they're in a format directly readable by qemu
code.
Currently the secret driver is lame and just stores the individual
files in base64 plain text. At some point I want to integrate the
secret driver with DEO[1], so that those files are encrypted. The
thing is that with DEO, the virtualization host would never actually
have access to the decryption key. The secret driver would read the
encrypted file, send it to DEO which decrypts it and sends back the
plain text. We would *not* want QEMU to ever talk to DEO directly,
so there would be no way for QEMU to directly read the secret
driver files and decrypt the data.
Regards,
Daniel
[1]
https://blog-ftweedal.rhcloud.com/2015/09/automatic-decryption-of-tls-pri...
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|