On Fri, Nov 15, 2013 at 6:28 PM, Apollon Oikonomopoulos <[email protected]> wrote: > Hi Michele, > > On 18:06 Fri 15 Nov , Michele Tartara wrote: >> On Thu, Nov 14, 2013 at 11:41 AM, Apollon Oikonomopoulos >> <[email protected]> wrote: >> > 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. >> >> I'm not sure I understand what you mean. Is the problem the fact that >> the instance can access the internet (which is desired anyway, even if >> we might want to make it optional)? >> Or the fact that the instance can access the host network? Because as >> far as I know they are not exactly in the same network (inside the >> instance the IPs are completely different, and the host cannot access >> the instance). > > Yes, the host cannot access the instance, but all traffic originating > from the instance to the network is routed by the host using normal > routing and appears to come from the host itself, which means that the > instance will be able to access all intra-cluster ports (e.g. SSH, RPC, > DRBD, VNC and whatever else is typically left open between Ganeti > nodes).
Ok, thanks for clarifying. It's definitely an important point to consider. > >> > 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. >> >> Exactly, and this fits with Guido's suggestion of not creating TAP >> devices on the host. >> >> To requirement here is to have the host accessing on >> 169.254.169.254:80 something that behaves as a web server. On the host >> side this could actually be implemented in any way (actual network >> interface, redirection of a single port, data sent to a file >> descriptor...). Do you have any suggestion about how this could be >> done (at least with KVM) in a secure way? > > You could use KVM's user stack using restrict and guestfwd to > essentially jail the instance and directly attach the instance's > outgoing http connections to a process on the host without actual IP > communication with the host. I also suspect this will work with Xen's > qemu-dm. Thanks for the pointers, I'll have a look at those. > > I'm away from home currently, so I'll give the whole document a more > thorough look on Sunday evening. And thanks for all the input. Have a nice weekend. Cheers, Michele -- Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores
