Hi Akihiro, Regarding option (b), I agree that it is not advisable for quantum to manage iptables rules that enforce tenant network isolation. However, in a common case where tenant networks occupy a large private address space (e.g. 10.0.0.0/8), running the dhcp and l3 agents on a single host could be trivially accomplished by adding a static rule that drops packets whose src and dest ips are within the private range. Do you think this is worth documenting, at the least?
Thanks, Maru On 2013-01-28, at 1:14 AM, Akihiro MOTOKI <[email protected]> wrote: > Hi, > >>>>>> Date: Wed, 23 Jan 2013 23:42:55 -0800 >>>>>> From: Dan Wendlandt <[email protected]> >>>>>> Subject: Re: [Quantum-core] communication between unconnected >>>>>> subnetswithout namespace >> >> Hi guys, >> >> Sorry, I've had this half-written for a while. >> >> Thanks for bringing this up Akihiro. This is a topic we discussed a long >> time ago, but let die. >> Based on those discussions, I think the issues are even more substantial >> than what you mention. >> >> First, some context from those not familiar with the details. >> >> Bboth the quantum-l3-agent and quantum-dhcp-agent where originally designed >> focused on a model >> where they only used namespaces. This means that the IP interfaces used by >> the agents are >> completely disconnected not just from other router namespaces, but also from >> the "root" namespace >> (this is the namespace you associate with the standard IP connectivity of >> the host, i.e., the one >> you see when running ifconfig from a shell). >> >> However, some older platforms (e.g., RHEL) don't support namespaces (or >> perhaps have kernel >> support, but do not support the userspace utilities that we use to >> manipulate namespaces, see: >> http://docs.openstack.org/trunk/openstack-network/admin/content/ch_limitations.html). >> As a >> result, we added a flag, use_namespaces, to control this behavior. >> https://github.com/openstack/ >> quantum/blob/master/etc/l3_agent.ini#L23 >> >> However, if namespace are not use at all, the IP interfaces created by the >> l3 and dhcp agents are >> all in the root namespace with zero isolation. The issue you mention (using >> the DHCP as the >> gateway IP to reach another subnet when one is supposed to be on a isolated >> network) is just one >> example. It would also be the case that tenants with access to the quantum >> router would also be >> able to reach any subnet the the physical box running the l3-agent is >> connected to (e.g., a >> management network). Likewise, if either DHCP or routing is running without >> namspaces, any >> services running on the box and bound to the 0.0.0.0 address (e.g., SSH) >> would likely also be >> exposed to VMs on the logical network, since the 0.0.0.0 listening address >> would include the IP >> address of the DHCP server. I believe both of the latter items are still a >> problem even if you do >> not run dhcp + l3 together on a server with namespaces disabled. > > Thanks for clarifying the issues. > I agree with your description. > > I think the issues can be categorized into two: > (a) isolation between tenants and a provider, and > (b) isolation among tenants (networks) > The former is what Dan mentionded and the latter is what I wrote. > > To address (a), we need to setup static iptables rules appropriately: > - Allow INPUT to management L4 ports only from a management network. > - Disallow FORWARD from/to an interface connected to a management network. > Concrete examples in the doc would be helpful. > I may miss some required rules. If so please correct me. > > Regarding address (b), it cannot be addressed by static rules and > we need to avoid to run dhcp-agent and l3-agent on a server. > > Akihiro > >> If people agree with the above descriptions, let's file an urgent doc bug on >> this, and get it >> pushed. There are some potential code work-arounds (e.g., pushing down >> iptables filters to >> restoring the required isolation) that we could explore if desirable, though >> I would much prefer >> that we are able to converge on using a single namespace-based design that >> does not require extra >> bagge for isolation. >> >> Dan >> >> On Fri, Jan 11, 2013 at 6:24 AM, Gary Kotton <[email protected]> wrote: >> >> On 01/11/2013 02:30 PM, Akihiro MOTOKI wrote: >> >> Hi folks, >> >> I have noticed that there is a case two subnets not connected >> each other via a router can communicate each other >> by changing default gateway to the IP address of the DHCP servers >> in a setup where l3-agent and dhcp-agent run on a same host without >> namespace. >> >> A simple solution to avoid it is to run l3-agent and dhcp-agent on >> different hosts. >> Is there any other good solution? >> >> IMO, this is a limitation without namespace on deployment >> rather than a bug of quantum and should be documented in the guide. >> >> This sounds reasonable. Maybe this should be documented. >> >> What do you think? >> >> Thanks, >> Akihiro >> >> -- >> Mailing list: https://launchpad.net/~quantum-core >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~quantum-core >> More help : https://help.launchpad.net/ListHelp >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Dan Wendlandt >> Nicira, Inc: www.nicira.com >> twitter: danwendlandt >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> > > -- > Mailing list: https://launchpad.net/~quantum-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~quantum-core > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
