For the past few months I have been looking at KVM virtualization on Red Hat Enterprise Linux and CentOS and just recently started looking at KVM security. I have a small deployment in my lab with a few Dell PowerEdge servers, EqualLogic iSCSI storage and several Linux Virtual Machines (VMs), and even though security is not a major concern in a lab environment, I learned a few interesting things about KVM virtualization security that I’d like to share with you.

Security in a virtualized environment can be divided into three different components: Hypervisor (physical server) security, VM security and remote management security. Because hypervisor and VM security are beyond the scope of a blog, I will just provide a brief overview for them and instead focus on a couple of methods to provide secure remote management.

Hypervisor security

Hypervisor security involves restricting access to the virtualization host and should be no different than for non-virtualized hosts. The usual tools can be used to secure a KVM host, including iptables and SELinux. You can implement additional measures such as isolating VM network traffic from the hypervisor’s, thus limiting the hypervisor’s exposure from external attacks. Hypervisor security is critically important, because if a hypervisor is compromised, then all VMs running on it can be compromised as well.

VM security

VM security encompasses not just securing the OS running on the VMs (which would be no different than a physical host) but also securing the VM images from within the hypervisor. Because VM images are accessible from the hypervisor either on local or remote storage, measures should be taken to secure VM images just like any other sensitive data. There are different options available, including VM image encryption and the sVirt service.

Remote management security

Remote management involves managing virtual resources (storage and VMs) on KVM hosts remotely. Remote management can be very useful when you want to delegate management of the virtualized environment to other users without granting login access to the KVM hypervisor.

The libvirtd daemon is responsible for managing all virtual resources on a KVM host, and there are client tools, such as ‘virsh’ and ‘virt-manager’ that can interact with it remotely. In the following section I describe two simple methods for connecting securely to libvirtd: SSH tunnels and SASL (Simple Authentication and Security Layer).

SSH Tunnels: This method uses SSH to remotely connect to the hypervisor and does not require any prior configuration. It requires SSH login credentials on the hypervisor for a user that can manage virtualization resources, which by default only ‘root’ can do, but could be changed so that non-root accounts can be used.

From a remote management client, you can run for example:

# virsh -c qemu+ssh:// list's password:

Id Name                 State


  1 vm1                 running

  2 vm2                 shut off

# virsh -c qemu+ssh:// start vm2's password:

  Domain vm2 started

# virsh -c qemu+ssh:// list's password:

Id Name                 State


  1 vm1                 running

  2 vm2                 running


SASL: This method provides secure authentication and data encryption. In its most simple implementation, a separate user credential database is created to authenticate with the libvirtd daemon. One advantage with this method is that non-login user ids can be used to manage virtualized resources on a KVM host.

To configure a KVM host to use SASL, do the following:

1. Edit /etc/libvirt/libvirtd.conf and change:

   listen_tls = 0             # Disable the listen_tls flag

   listen_tcp = 1            # Enable the listen_tcp flag

      auth_tcp = “sasl”    # Set the authentication scheme

2. Edit /etc/sysconfig/libvirtd and uncomment this line to make libvirtd listen for TCP/IP connections:


3. On the KVM host, open firewall port 16509/TCP:

   # iptables -A INPUT -p tcp -m tcp --dport 16509 -j ACCEPT

   # service iptables save

4. Restart the libvirtd daemon for changes to take effect:

    # service libvirtd restart

5. Finally, add users to the user database. In this example, we are adding the user ‘admin’ to the ‘libvirt’ SASL database:

   # saslpasswd2 –c –a libvirt admin


   Again (for verification):

6. Now that SASL is configured, you can connect to the KVM hypervisor securely:

   # virsh -c qemu+tcp:// list

   Please enter your authentication name: admin

   Please enter your password:

   Id Name                 State


     1 vm1                 running

     2 vm2                 running


SSH Tunnels and SASL can be used to run any virsh command. For a full list of options available, refer to the virsh man page.