cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nux! <...@li.nux.ro>
Subject Re: KVM: Security grouping through libvirt instead of Python
Date Wed, 06 Jan 2016 15:42:15 GMT
Ok, as long as compatibility is maintained, then awesome!

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.


[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" <wido@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" <wido@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" <wido@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

Mime
View raw message