On Tue, Mar 07, 2017 at 05:27:55PM -0800, ashish mittal wrote: > Thanks! There is one more input I need some help with! > > VxHS network library opens a fixed number of connection channels to a > given host, and all the vdisks (that connect to the same host) share > these connection channels. > > Therefore, we need to open secure channels to a specific target host > only once for the first vdisk that connects to that host. All the > other vdisks that connect to the same target host will share the same > set of secure communication channels. > > I hope the above scheme is acceptable?
I don't think I'm in favour of such an approach, as it forces a single QEMU process to use the same privileges for all disks it uses. Consider an example where a QEMU process has two disks, one shared readonly disk and one exclusive writable disk, both on the same host. It is reasonable as an administrator to want to use different credentials for each of these. ie, they might have a set of well known credentials to authenticate to get access to the read-only disk, but have a different set of strictly limited access credentials to get access to the writable disk Trying to re-use the same connection for multiple cause prevents QEMU from authenticating with different credentials per disk, so I don't think that is a good approach - each disk should have totally independant state. > > If yes, then we have a couple of options to implement this: > > (1) Accept the TLS credentials per vdisk using the previously > discussed --object tls-creds-x509 mechanism. In this case, if more > than one vdisk have the same host info, then we will use only the > first one's creds to set up the secure connection, and ignore the > others. vdisks that connect to different target hosts will use their > individual tls-creds-x509 to set up the secure channels. This is, of > course, not relevant for qemu-img/qemu-io as they can open only one > vdisk at a time. > > (2) Instead of having a per-vdisk --object tls-creds-x509, have a > single such argument on the command line for vxhs block device code to > consume - if that is possible! One way to achieve this could be the > user/password authentication we discussed earlier, which we could use > to pass the directory where cert/keys are kept. > > (3) Use the instance UUID, when available, to lookup the cert files > per instance (i.e. for qemu-kvm), and use the --object tls-creds-x509 > mechanism, when instance UUID is NULL (i.e. qemu-io, qemu-img etc). > The cert/key files are anyway protected by file permissions in either > case, so I guess there is no additional security provided by either > method. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
