From Fedora Project Wiki

Revision as of 17:59, 14 January 2009 by Markmc (talk | contribs) (add to virt category)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Virtualization Security

Summary

There are no secure remote management capabilities in Xen, KVM or QEMU. All areas where management of Xen, KVM or QEMU involves network connections need to be run with TLS encryption, and client/server certificate checking. The scope of this extends to management APIs, remote console (VNC) and guest migration between hosts.

Owner

  • Name: DanielBerrange

Current status

  • Targeted release: Fedora 8
  • Last updated: 2007-10-11
  • Percentage of completion: 100%


Usage cases/rationale

  • Secure remote management of guest VM lifecycle
  • Secure remote access to the guest virtual consoles
  • Secure remote provisioning of new guests
  • --(Secure migration of guests across physical hosts)--

Scope

Requires working with upstream libvirt, Xen, QEMU and KVM communities to achieve a consistent approach to security throughout the software stack. At very least must allow TLS encryption to be viable for large scale enterprise use. Supporting tunnelling over SSH connections is also desirable, but lower priority.

Test Plan

  • Setup x509 certificate authority
  • Install Xen or KVM virtualization on a host
  • Create x509 certificates for host
  • Setup Xen / KVM / libvirt to use x509 certs
  • Install virt-manager on a different host
  • Create x509 certificate for client
  • Setup virt-manager to use x509 certs
  • Connect to remote host in virt-manager
  • Provision new guest in virt-manager
  • --(Migrate a guest in virt-manager)--

Dependencies

libvirt, xen, qemu, kvm, virt-manager.

Details

REQUIRED

virt-manager (Complete)

  • Switch to using GTK VNC client widget to enable TLS support & more efficient wire encodings (Complete)
  • Enable UI for connecting to remote hosts (Complete)
  • Adapt UI to improve viewing of multiple concurrent hosts (Complete)

gtk-vnc (Complete)

  • Polish off API to state where it can be integrated with virt-manager (Complete)
  • Package in RPM format (Complete)
  • Get a formal upstream release made (Complete)
  • Get packages through Fedora review process (Complete)

virt-install (Complete)

  • Replace vncviewer with app using gtk-vnc. (Complete)

virt-viewer (Complete)

  • Do upstream release (Complete)
  • Get packages through Fedora review process (Complete)

libvirt

  • Merging of libvirt daemon patches with TLS support (Complete)

xen

  • --(Add code to do migration over a TLS secured connection)--
  • Merge TLS patches for VNC in QEMU (Complete)
  • Switch paravirt framebuffer daemon to use QEMU vnc code (Completed)

KVM

  • Merge TLS patches for VNC in QEMU (Complete)
  • --(Add code to do migration over a TLS secured connection)--

QEMU

  • Merge TLS patches for VNC in QEMU (primary upstream codebase) (Complete)

OPTIONAL

virt-manager

  • Provisioning of new guests remotely. Will require new libvirt APIs for storage management. Will require PXE support for all guests. (Postponed to F9)
  • New UI for migration of VMs. (Postponed to F9)

libvirt

  • New storage management APIs to allow enumeration & creation of storage devices (Postponed to F9)
  • New API for migration of VMs. (Complete)

Contingency Plan

The basic level of TLS support at the libvirt API layer is already complete. If the QEMU VNC TLS patches are not completed in time, virt-maanger will be restricted to only use SSH tunnels, rather than offering choice of TLS vs SSH.

Migration support is already optional bonus point and thus requires no contingency plan.

Documentation

Release Notes

TODO list: