Skip to content

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

@cfergeau

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions