Hello,
I’d like to request that prometheus-libvirt-exporter snap is automatically connected to the “libvirt” interface.
The snap purpose is to expose libvirt metrics in prometheus format and it needs that access to read them.
I think the request makes sense for the snap, +1.
With the libvirt interface, a snap “Can access the libvirt control socket, which gives privileged access to control libvirtd on the host. This is commonly used to create and manage QEMU/KVM instances on the host.”
While VMs are by their nature contained, I wonder about the possibility and trustability of allowing a snap to use this interface since it goes beyond just getting metrics; it grants also ability to stop/start, create, destroy and change resources to VMs.
I believe I understand the use case but also think it might be wise to leave the connection decision to the user, since this will likely be installed as part of a metrics gathering setup and perhaps the connection can be explicitly done by some automated means outside the snap.
Can you give me a bit more of an idea why it’d be desirable to autoconnect and whether my concerns above are justified?
Thanks,
- Daniel
Access to the libvirt socket give device ownership to the snap, since, for example, libvirt can export write access to raw disks on the host into the guest.
@roadmr the main reason it’s IMO desirable to autoconnect is “just works” user experience.
If somebody decides to install “prometheus-libvirt-exporter” snap I think they can reasonably assume that it will work once installed. I imagine most users will go through the following workflow:
- snap install prometheus-libvirt-exporter
- Confirm it’s listening on port 9177
- curl http://localhost:9177
If we autoconnect they’ll see metrics.
If we don’t then some will assume it’s broken and remove it. More persistent users will do some digging and find command needed to get it to work of course. What would make UX better is help text printed after snapp is installed but I’m not aware of any method to do that.
I agree that the libvirt interface grants much more than what’s needed but if it’s a matter of one extra manual step I don’t see it making very big difference from security perspective? Or am I missing something?
Something else worth keeping in mind is that I can’t think of any reason why somebody might install the snap but not connect it to the interface. Until it’s connected it’s not doing anything useful.
I hesitate to +1 granting autoconnect of such a powerful interface (TIL about what jdstrand mentioned, which just adds to my concerns) in the interest of simply “just works”.
The “the snap is useless without this interface” argument can be used as well for something malicious that owns the device: “I can’t effectively delete all your snaps and be evil until you connect me to snapd-control, but if I’m autoconnected then the world’s my oyster” so I don’t believe it holds. For these interfaces, my feeling is it has to be a conscious, explicit decision beyond installing the snap.
For that matter, I’d almost prefer this to be classic: at least then a warning is printed “this snap is all-powerful and can do all kinds of mischief on your system, if you agree install it with --classic”.
Ideally the capabilities of the interface would be explained prior to a) the user installing the snap or b) the user actually using the snap. There are, however, no mechanisms to do so, as you mention (something that did “a” would be fantastic but would screw up the interactive use case).
The pattern I’ve used sometimes is to add a readme command to the snap. S if the user installs it, then does prometheus-libvirt-exporter<tab> they’ll see there’s a readme command, and when run this will explain what they need to do.
A possible mitigator, as well, would be having this published by a verified or well-known developer (maybe transfer this snap to snapcrafters or upstream?). As is, one would ask “who is Jacek and why does his snap want to own my VMs?” (I know and trust you but we’re talking about users at large).
I’m +0 (abstain) on granting this autoconnect; as explained above I don’t like it but also can’t offer a good alternative, so prefer to bow out so maybe another reviewer can tilt the scale decisively or propose options that would mitigate my concerns. I’m totally open to changing my vote if such an option does show up 
I would much rather see promotheus-libvirt-exporter detect whether or not it can access the socket, and let the user know that they must connect it. In this manner there is a context and the user can make the choice on this powerful interface. Put another way, while ‘libvirt’ is in the name of the snap, the name of the snap suggests it just gathers data and it is surprising that it could launch VMs, mount filesystems, export disks, adjust networking, etc, etc. I’m not suggesting you change the name of the snap-- the libvirtd socket is just way too powerful and there aren’t any fine-grained controls on it.
-1 to auto-connect
1 vote for, 1 vote against, 1 abstained.
@natalia, does your vote change in light of the new information. @reviewers - can one or more of you vote to break the tie?
Hey @jdstrand,
Yes, my vote changes in light of the new information, I think the interface should not be autoconnected. Thanks @roadmr for the research done.
Retally - 0 votes for, 2 against, 1 abstained. Not granting the auto-connection.
Thank you everyone for looking into this!
I’ll work around the connection problem in the charm and if possible also update the software to print human readable error.