I've read all the drafts and changes and I don't have any suggestions,
looks great!

Is the doc change sufficient, or should the doc also roll this much detail
into the migration instructions? We've merged all the changes that avoid
the too-open recommendation, but should we also not consider this bug
closed until the instructions are in the doc itself?


On Wed, Mar 5, 2014 at 2:43 PM, Nathan Kinder <email address hidden> wrote:

> I added some additional content to the "Recommended Actions" section.
> The additional content covers configuring the list address for the
> epehmeral migration ports, the ability to tunnel migration traffic over
> the remote access port, and details about securing the live block
> migration traffic.
>
> I believe this gives a more complete picture of how live migration
> can/should be secured.  It also will allow this single OSSN to cover the
> issues described in bug 1240554 instead of having two separte (but
> similar) OSSNs.
>
> The new/reworked sections are below.  Feedback would be appreciated.
>
> ----------------------------------------------------------------------
> In addition to requiring authentication for remote access to the libvirt
> daemon
> on your OpenStack Compute nodes, it is also recommended to restrict network
> access such that connectivity is only allowed between the Compute nodes.
>
> The first thing that should be done is to restrict the network interfaces
> that
> the libvirt daemon listens on for remote connections.  By default, the
> libvirt
> daemon listens on all interfaces when remote access is enabled.  This can
> be
> restricted by setting the following configuration directive in
> /etc/libvirt/libvirtd.conf:
>
> ---- begin example libvirtd.conf snippet ----
> listen_addr = <IP address or hostname>
> ---- end example libvirtd.conf snippet ----
>
> Migration in the libvirt daemon also uses a range of ephemeral ports by
> default.  The connections to these ephemeral ports are not authenticated or
> encrypted.  It is possible to tunnel the migration traffic over the regular
> libvirt daemon remote access port, which will use the authentication and
> encryption settings that you have defined for that port.  It is recommended
> that you do this for the additional security that it provides.  To enable
> tunneling of the migration traffic, you must tell your OpenStack Compute
> nodes to set the VIR_MIGRATE_TUNNELLED flag for live migration.  This is
> done
> by setting the following directive in /etc/nova/nova.conf:
>
> ---- begin example nova.conf snippet ----
> live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER,
> VIR_MIGRATE_TUNNELLED
> ---- end example nova.conf snippet ----
>
> The tunneling of migration traffic described above does not apply to live
> block
> migration.  Live block migration is currently only possible over ephemeral
> ports.
>
> If you choose to use the ephemeral migration ports, there are a few things
> that
> you should be aware of.  Unfortunately, there is no way to restrict the
> network
> interfaces that these ephemeral ports will listen on in libvirt versions
> prior
> to 1.1.4.  If you are running version 1.1.4 or later of the libvirt
> daemon, you
> can set the following directive in /etc/libvirt/qemu.conf to specify what
> interfaces are used for the ephemeral migration ports:
>
> ---- begin example qemu.conf snippet ----
> migration_address = <IP address>
> ---- end example qemu.conf snippet ----
>
> It is also recommended to configure the firewall on each OpenStack Compute
> node
> to only allow other Compute nodes to access the ports that are used for
> remote
> access to the libvirt daemon.  By default, this is port 16514 for TLS and
> 16509
> for unencrypted TCP.
>
> Additionally, migration over ephemeral ports uses a port range of
> 49152-49215.
> You will need to allow your OpenStack Compute nodes to communicate with
> each
> other over these ports if you choose not to tunnel the migration traffic
> over
> the libvirt daemon remote access port.
>
> You can check what ports you have configured for the libvirt daemon by
> looking
> at the following configuration directives:
>
>   tls_port (libvirtd.conf)
>   tcp_port (libvirtd.conf)
>   migration_port_min (qemu.conf)
>   migration_port_max (qemu.conf)
>
> If you are running a version of the libvirt daemon older than 1.1.4 and you
> want to perform live block migration, you will need to allow your OpenStack
> Compute nodes to communicate over port range 5900-49151.  If you are
> running
> version 1.1.4 or later of the libvirt daemon, the regular ephemeral
> migration
> port range is used for live block migration.
>
> Please consult the documentation for your firewall software for
> instructions on
> configuring the appropriate firewall rules.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1287194
>
> Title:
>   Docs recommend insecure configuration option
>
> Status in OpenStack Manuals:
>   New
> Status in OpenStack Security Advisories:
>   Won't Fix
> Status in OpenStack Security Notes:
>   In Progress
>
> Bug description:
>   From Daniel Berrange:
>
>   ---------
>   I just came across the following docs for configuring migration with
>   nova+libvirt+kvm
>
>
> http://docs.openstack.org/trunk/config-reference/content//section_configuring-compute-migrations.html
>
> http://docs.openstack.org/grizzly/openstack-compute/admin/content//configuring-migrations.html
>
>   At point 7 the docs say
>
>    7. Update the libvirt configurations. Modify the
>   /etc/libvirt/libvirtd.conf file:
>
>     before : #listen_tls = 0
>     after : listen_tls = 0
>     before : #listen_tcp = 1
>     after : listen_tcp = 1
>     add: auth_tcp = "none"
>
>     Modify the /etc/init/libvirt-bin.conf file:
>
>     before : exec /usr/sbin/libvirtd -d
>     after : exec /usr/sbin/libvirtd -d -l
>
>   What this does is tell the libvirt daemon listen for client TCP
> connections
>   on all network interfaces, and accept any clients performing absolutely
>   zero authentication.
>
>   Sure this works for migration, but it also allows anyone of the network
>   to be able to completely own all your compute hosts, by invoking whatever
>   libvirt API calls they like.
>
>   This is equivalent to telling someone to configure SSH to allow root
>   logins with no passwords or keys at all. Actually it is worse because
>   as well as killing authentication, it kills any encryption too.
>
>   Libvirt has a choice of 4 secure options for remote access over TCP
>
>    - SSH tunnel to libvirtd's UNIX socket
>    - libvirtd TCP socket, with GSSAPI/Kerberos for auth+data encryption
>    - libvirtd TCP socket, with TLS for encryption and x509 client
>      certs for authentication
>    - libvirtd TCP socket, with TLS for encryption and Kerberos for
>      authentication
>
>   documenting any of these setups would be better than what's there
>   now, which needs to be removed asap.
>
>   I don't know whether these docs are the current supported / preferred
>   docs for this - they're just what I found via google. If we have other
>   docs covering migration setup, they should be checked too.
>   ----------------
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openstack-manuals/+bug/1287194/+subscriptions
>