[virt-tools-list] virt-install and cloud-init, feedback wanted

[Daniel P. Berrangé]

On Thu, Nov 21, 2019 at 08:40:12AM +0100, Florian Weimer wrote:
> * Cole Robinson:
> 
> > One more point: my main interaction with cloud-init has historically
> > been by grabbing a Fedora/RHEL cloud image, passing it to
> > virt-install/virt-manager, and watching the boot hang, because there's
> > no data provider and cloud-init times out talking to the network, and
> > then I can't log in. I expect many people have hit this issue before.
> > I've always worked around this by using 'virt-customize' to disable
> > cloud-init and reset the root password. That's about the extent of my
> > usage here, which is broadly why the bare `--cloud-init` is the way it was.
> 
> This is also my use case. 8-/
> 
> > I'm also thinking to the future, if one day virt-install can detect that
> > it was passed a distro cloud-init image, perhaps we can invoke some
> > default behavior that gives the user a better chance of this config
> > being usable out of the box. I figure that will match whatever we choose
> > for the bare '--cloud-init' behavior
> 
> This goes probably in a different direction of what has been implement
> so far, but would it actually harm to enable the network-based
> instance-data injection by default?  The advantage would be that it also
> blocks these requests from leaking to untrusted parties, which could
> then serve bogus data to compromise the virtual machine.

I don't understand what you mean by leaking data to untrusted parties
here in contetx of config drive ? I've considerd the config drive to
be more secure / less risky than network service.

Use of the ISO image should really minimize the risk of unexected data
leakage, because the ISO image is restricted access on the host and
is only granted to the specific QEMU process, with SELinux enforcement
between each VM & other processes/users on the host.

With a network based service there are many greater risks of data leakage
I think. There is no SELinux separation between data for each VM. The
metadata service holds all the data for all VMs. There's also the risk
of the metdata service being accessed from processes on the host, or even
on the WAN.

If the network service is placed on a separate subnet, then you've got
the mgmt problem of creating an extra NIC for the guest and extra device
on the host to attach it to, and managing firewall rules to correctly
isolate the metadta service from unintended access.

Many OSP deployments refuse to enable the metadata service because they
consider it exposes more attack vectors than configdrive does.

Having said all that metadata service can be useful from a managability
POV because it is a live data channel, and thus enables you to change the
data being served while the VM is running. This can be useful for the
userdata blob. Config drive is fixed at time the VM boots.

Network metadata service though is out of scope for virt-install. If
someone ones to deploy one they can do so already today without needing
any more features in virt-install.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|