cluster-api-provider-libvirt seems built on very wrong premises :(

[cfergeau]

README.md says to modify libvirtd.conf:

listen_tls = 0
listen_tcp = 1
auth_tcp="none"
tcp_port = "16509"

and the libvirtd systemd service:

/usr/sbin/libvirtd -l

This is roughly equivalent to asking people to configure remote password-less root access to the host!

If you can connect to qemu:///system, you can for example create a storage pool with:

<pool type='dir'>
  <name>hack</name>
  <source>
  </source>
  <target>
    <path>/etc</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:etc_t:s0</label>
    </permissions>
  </target>
</pool>

and then read/write to any file in /etc (for example /etc/shadow).
We could restrict this libvirtd access to connections from the cluster, but I don't think we want the anything running in the cluster to be able to escape into the host.
We could use qemu+ssh:// and ssh keys, or qemu+tls:// and client certificates, and protect these secrets from most of the cluster, but I'm not familiar at all with openshift security, so I don't know if this is acceptable or not.

[cfergeau]

After further discussion, I was pointed out at https://libvirt.org/aclpolkit.html which may be usable to restrict what can be done with the libvirt API, and also at https://github.com/openshift/cloud-credential-operator which manages fine-grained credentials in the AWS case (but probably not going to be applicable to libvirt).

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[cfergeau]

/remove-lifecycle stale

[cfergeau]

/lifecycle frozen