Thanks Wido, Let's see what the others think of it.
-- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Wido den Hollander" <w...@widodh.nl> > To: dev@cloudstack.apache.org > Sent: Wednesday, 6 January, 2016 16:30:57 > Subject: Re: KVM: Security grouping through libvirt instead of Python > On 06-01-16 16:42, Nux! wrote: >> Ok, as long as compatibility is maintained, then awesome! >> > > Yes > >> BTW, I might be going too far, but would this allow us to "live" change the >> SGs >> of an instance? >> Until very recently this was not possible at all, but last week the folks >> from >> Exoscale added a patch[1] that allows one to change the SGs of an instance, >> however the instance must be stopped/started. >> > > Seems like it. If we create a specific filter for each instance running > on that host we can re-define the filter at any moment as long as the > name and UUID stays the same. > > Security Group Rules -> Libvirt XML > > That way you can simply re-generate the XML and thus switch security > group while the Instance is running. > > Wido > >> >> [1] https://github.com/apache/cloudstack/pull/1297 >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >>> From: "Wido den Hollander" <w...@widodh.nl> >>> To: dev@cloudstack.apache.org >>> Sent: Wednesday, 6 January, 2016 15:37:39 >>> Subject: Re: KVM: Security grouping through libvirt instead of Python >> >>> On 06-01-16 16:20, Nux! wrote: >>>> That's great! Fine by me then, but we need to be careful and not mess up >>>> the SG >>>> bits for XenServer. >>>> >>>> I think they are sharing the same python scripts right now. >>>> >>> >>> No reason to delete the Python script from the Git repo. For KVM we can >>> however switch to using libvirt and just generate XMLs and call the API >>> functions. >>> >>> Wido >>> >>>> -- >>>> Sent from the Delta quadrant using Borg technology! >>>> >>>> Nux! >>>> www.nux.ro >>>> >>>> ----- Original Message ----- >>>>> From: "Wido den Hollander" <w...@widodh.nl> >>>>> To: dev@cloudstack.apache.org >>>>> Sent: Wednesday, 6 January, 2016 14:38:17 >>>>> Subject: Re: KVM: Security grouping through libvirt instead of Python >>>> >>>>> On 06-01-16 13:12, Nux! wrote: >>>>>> Hi Wido, >>>>>> >>>>>> +1 for using more libvirt and less custom stuff, but what do we do about >>>>>> XenServer? SG is supported with it as well and there is no libvirt there. >>>>>> Would this be a different implementation just for KVM? >>>>>> >>>>> >>>>> Yes. For KVM we control almost everything through libvirt. Moving >>>>> Security Grouping there would be a good thing. >>>>> >>>>> I never do anything with Xen, so I have no clue there. >>>>> >>>>>> In addition, I have the following in production and it's not clear if it >>>>>> would >>>>>> continue to work with libvirt filters - my hunch is that it will not >>>>>> since it >>>>>> involves multiple, different src IPs. >>>>>> >>>>>> 1 - additional IPs on instance >>>>>> 2 - subnets routed via instance IPs (I usually assign them on loopback >>>>>> on the >>>>>> VM) >>>>>> >>>>> >>>>> No problem at all. Just tested this: >>>>> >>>>> <rule action='return' direction='out' priority='500'> >>>>> <ip srcipaddr='192.168.100.101'/> >>>>> </rule> >>>>> <rule action='return' direction='out' priority='501'> >>>>> <ip srcipaddr='192.168.100.201'/> >>>>> </rule> >>>>> <rule action='return' direction='out' priority='502'> >>>>> <ip srcipaddr='10.0.0.0' srcipmask='24'/> >>>>> </rule> >>>>> >>>>> <rule action='drop' direction='out' priority='1000'/> >>>>> >>>>> So this VM had this config: >>>>> >>>>> auto ens7 >>>>> iface ens7 inet static >>>>> address 192.168.100.101 >>>>> netmask 255.255.255.0 >>>>> >>>>> auto ens7:0 >>>>> iface ens7:0 inet static >>>>> address 192.168.100.201 >>>>> netmask 255.255.255.0 >>>>> >>>>> auto dummy0 >>>>> iface dummy0 inet static >>>>> address 10.0.0.1 >>>>> netmask 255.255.255.0 >>>>> >>>>> From my other host I could reach all IPs just fine: >>>>> >>>>> $ ip route add 10.0.0.0/24 via 192.168.100.101 >>>>> >>>>> Trying to use any other IP than listed in the filter would be dropped. >>>>> >>>>> So it can support multiple IPs and routed subnets as well. The latter >>>>> would be required for IPv6 with DHCPv6+Prefix Delegation. >>>>> >>>>> Wido >>>>> >>>>>> Lucian >>>>>> >>>>>> -- >>>>>> Sent from the Delta quadrant using Borg technology! >>>>>> >>>>>> Nux! >>>>>> www.nux.ro >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Wido den Hollander" <w...@widodh.nl> >>>>>>> To: dev@cloudstack.apache.org >>>>>>> Sent: Wednesday, 6 January, 2016 10:02:31 >>>>>>> Subject: KVM: Security grouping through libvirt instead of Python >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> A while back I opened CLOUDSTACK-1164 [0] since I think that we should >>>>>>> use as much features of libvirt as possible. >>>>>>> >>>>>>> libvirt supports network filtering [1] which basically controls >>>>>>> ebtables, iptables and ip6tables (IPv6 support!). >>>>>>> >>>>>>> Using a XML definition you can create a filter and than use this filter >>>>>>> for a interface. >>>>>>> >>>>>>> I created a simple setup to test: >>>>>>> - Can I prevent MAC spoofing? >>>>>>> - Can I prevent IP spoofing? >>>>>>> - Can I reload a filter without stopping my VM >>>>>>> >>>>>>> All the questions were answered by "Yes", so I figured it was useful to >>>>>>> share this information. >>>>>>> >>>>>>> On my laptop running Ubuntu 14.04 and libvirt 1.2.2 I created two VMs: >>>>>>> - One NIC with NAT for Internet access (no filter) >>>>>>> - One NIC on a isolated bridge >>>>>>> >>>>>>> On the second NIC I assigned 192.168.100.1 and .2. >>>>>>> >>>>>>> VM network_filter_1 got a filter assigned: >>>>>>> >>>>>>> <interface type='network'> >>>>>>> <mac address='52:54:00:c1:b9:5b'/> >>>>>>> <source network='filternetwork'/> >>>>>>> <model type='virtio'/> >>>>>>> <filterref filter='network_filter_1'/> >>>>>>> </interface> >>>>>>> >>>>>>> I created a filter called 'network_filter_1' >>>>>>> >>>>>>> <filter name='network_filter_1' chain='ipv4'> >>>>>>> <uuid>64b80046-9a9d-40c2-8782-ed5878146262</uuid> >>>>>>> >>>>>>> <rule action='drop' direction='out'> >>>>>>> <mac match='no' srcmacaddr='52:54:00:c1:b9:5b'/> >>>>>>> </rule> >>>>>>> >>>>>>> <rule action='drop' direction='out'> >>>>>>> <ip match='no' srcipaddr='192.168.100.1'/> >>>>>>> </rule> >>>>>>> >>>>>>> <rule action='accept' direction='in'> >>>>>>> <tcp dstportstart='22'/> >>>>>>> </rule> >>>>>>> >>>>>>> <rule action='accept' direction='in'> >>>>>>> <tcp dstportstart='80'/> >>>>>>> </rule> >>>>>>> >>>>>>> <rule action='accept' direction='in'> >>>>>>> <tcp dstportstart='443'/> >>>>>>> </rule> >>>>>>> >>>>>>> <rule action='drop' direction='in'> >>>>>>> <all/> >>>>>>> </rule> >>>>>>> </filter> >>>>>>> >>>>>>> libvirt can auto-detect the MAC and IP, but since we already know that >>>>>>> information I didn't think I needed to test that. >>>>>>> >>>>>>> $ virsh nwfilter-define filter.xml >>>>>>> $ virsh define network_filter_1.xml >>>>>>> $ virsh start network_filter_1 >>>>>>> >>>>>>> The result was simple. Using any different IP then 192.168.100.1 failed >>>>>>> and connections to ports not being 22, 80 or 443 failed. >>>>>>> >>>>>>> Changes to filters were simple as well. Edit filter.xml and run: >>>>>>> >>>>>>> $ virsh nwfilter-define filter.xml >>>>>>> >>>>>>> Those changes were applied without stopping the VM. Done within 1 >>>>>>> second. >>>>>>> >>>>>>> I think it is worth the effort to use this instead of using >>>>>>> 'security_group.py'. >>>>>>> >>>>>>> On KVM we can always perform MAC address filtering and when security >>>>>>> grouping in shared or basic networking is used we can use libvirt to >>>>>>> filter all the traffic. >>>>>>> >>>>>>> Less code we have to maintain and I prefer using libvirt over our custom >>>>>>> Python code. >>>>>>> >>>>>>> This is not a functional spec yet, but I just wanted to get this >>>>>>> information out there and share what I found. >>>>>>> >>>>>>> Looking at the libvirt docs I can't find anything which it can't do >>>>>>> which our security groups currently can. It already fully supports IPv6 >>>>>>> which we don't. >>>>>>> >>>>>>> CloudStack would only need to generate the proper XML documents and >>>>>>> that's all. >>>>>>> >>>>>>> Wido >>>>>>> >>>>>>> [0]: https://issues.apache.org/jira/browse/CLOUDSTACK-1164 > >>>>>> [1]: http://libvirt.org/formatnwfilter.html
