cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: KVM: Security grouping through libvirt instead of Python
Date Wed, 06 Jan 2016 16:30:57 GMT


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" <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