On 09:57 Wed 13 Nov , Michele Tartara wrote: > On Tue, Nov 12, 2013 at 2:13 PM, Guido Trotter <[email protected]> wrote: > > On Tue, Nov 12, 2013 at 12:41 PM, Michele Tartara <[email protected]> > > wrote: > >> + > >> +When the communication mechanism is enabled, Ganeti will create a new > >> network > >> +interface inside the instance. This extra network interface will be the > >> last one > >> +of the instance, after all the user defined ones. On the host side, this > >> +interface will be only accessible to the host itself, and not be routed > >> outside > >> +the machine. > > > > Actually it would be great if we didn't even have to create the tap. > > Do you mean something like (for kvm): > -net user,net=169.254.169.0/24,host=169.254.169.254 > that starts a user network showing the host as reachable with address > 169.254.169.254?
We should be careful when using KVMs userspace stack in that context. It will effectively place the instance in the same network as the hardware node itself, which is a serious security issue (especially with user-provided images). There is a `restrict' option for the userspace stack, which could help things, but it also blocks the host. The special network interface is an interesting idea, but I'm afraid it has some far-reaching implications. Until now, the node network configuration (interface configuration, firewalling etc) was left up to the network administrator. Thus, nodes may have a firewall each or they may share a perimeter firewall on some router. When using bridged instances (which AFAICT is probably the norm), this is fine because instance IPv4 traffic never touches the node's TCP/IP stack. However if, as proposed, we create a new tap interface with an address on the host, then care must be taken not to expose the whole node at layer 3 to the instance. This implies managing the firewall - at least partially - which should be done cooperatively with the node's administrator. Apollon
