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
