On 09/04/2015 05:09 PM, Russell Bryant wrote:
> I've been working on Neutron security groups for OVN a bit this week and
> have the first rough cut "working" (it does something, at least). Right
> now it only creates ACLs on neutron port creation. I have to go back
> and add cleanup, handle when ports or security groups get updated after
> they are created, ...
>
> Anyway, I definitely found myself getting confused with Neutron's SG
> ingress vs. egress, OVN ACL direction inbound vs. outbound, and when to
> use OVN inport and outport associated with each. So, here's the
> simplest example. Let me know which part doesn't match what you'd
> expect, because surely I've got something backwards.
I just saw the RFC patch for OVN ACLs and the related schema patch.
Renaming inbound/outbound to to-lport/from-lport helps a lot. The
associated docs helped clarify for me, as well. Thanks!
> The "default" security group created by Neutron is this:
>
>> $ neutron security-group-list
>> +--------------------------------------+---------+----------------------------------------------------------------------+
>> | id | name | security_group_rules
>> |
>> +--------------------------------------+---------+----------------------------------------------------------------------+
>> | b5e2bd3c-241d-41f8-b883-1586955078c0 | default | egress, IPv4
>> |
>> | | | egress, IPv6
>> |
>> | | | ingress, IPv4,
>> remote_group_id: b5e2bd3c-241d-41f8-b883-1586955078c0 |
>> | | | ingress, IPv6,
>> remote_group_id: b5e2bd3c-241d-41f8-b883-1586955078c0 |
>> +--------------------------------------+---------+----------------------------------------------------------------------+
>
> (To make it easier to talk about direction, I'm going to talk about the
> perspective of a VM.)
>
> What this means is that all outgoing IPv4 and IPv6 traffic from a VM
> should be allowed. Incoming IPv4 and IPv6 traffic to a VM that
> originated from another VM using the same security group is allowed.
> VMs can talk to the world and each other, but the world is not allowed
> to talk to the VMs.
>
> The Neutron plugin creates ACLs with 2 priorities. The numbers are
> arbitrary. It just needs 2 of them. It uses 1001 to create default
> drop rules. It then adds a rule with a priority of 1000 for each
> allow-related rule.
I realized I got the priorities backwards.
> The default drop rules look like this (the quote escaping is done by the
> output of ovsdb-client):
>
> ACL:
> priority: 1001
> direction: inbound
All cases of "inbound" should now be "to-lport".
Similarly, all cases of "outbound" should now be "from-lport".
> action: drop
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "outport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\""
I think I need to make this a little less restrictive by adding " &&
ip". The ACL docs in one of Justin's patches helpfully points out:
+ By default all traffic is allowed. When writing a more
+ restrictive policy, it is important to remember to allow flows
+ such as ARP and IPv6 neighbor discovery packets.
> ACL:
> priority: 1001
> direction: outbound
> action: drop
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "inport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\""
>
> The 4 ACL entries here correspond to the 4 security group rules
> associated with the "default" security group as shown in the output of
> "neutron security-group-list" above.
>
> ACL:
> priority: 1000
> direction outbound
> action: allow-related
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "inport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\" && ip4"
>
> ACL:
> priority: 1000
> direction outbound
> action: allow-related
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "inport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\" && ip6"
>
> (Note that the set of UUIDs is the set of ports that use the same
> security group.)
>
> ACL:
> priority: 1000
> direction inbound
> action: allow-related
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "outport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\" && ip4 &&
> inport ==
> {\"192e5d75-2aac-4213-8bea-81d1322b3ed2\",\"1e6355f5-b6e4-43e3-8e89-aac1836424f8\",\"474febf6-0b68-4807-add7-32fd0de61ff6\",\"5fc806a5-e909-40a7-b037-9d50242596a5\",\"6fdfc7ed-94b9-4be2-92cd-ba56c0c07b3c\",\"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\",\"a6474b44-c091-4be5-a19c-aee8f7529d72\",\"a708bf55-aff7-4cc9-baf4-cc6f7a73e0ca\",\"c092c75d-a342-4f55-b421-c00e15cb4872\",\"d770254e-cc0d-4951-8040-cb7c1fec6961\",\"daceec7d-03db-4f1b-83a3-8a3621693e47\",\"dda41f17-9d8d-4064-8ef5-fd139dc49172\",\"f96a2351-b604-43b0-a34f-54fd861edfc9\"}"
>
> ACL:
> priority: 1000
> direction inbound
> action: allow-related
> external_ids: {"neutron:lport"="9d0876ea-9191-4d75-83b4-7e20b6d7ad11"}
> match: "outport == \"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\" && ip6 &&
> inport ==
> {\"192e5d75-2aac-4213-8bea-81d1322b3ed2\",\"1e6355f5-b6e4-43e3-8e89-aac1836424f8\",\"474febf6-0b68-4807-add7-32fd0de61ff6\",\"5fc806a5-e909-40a7-b037-9d50242596a5\",\"6fdfc7ed-94b9-4be2-92cd-ba56c0c07b3c\",\"9d0876ea-9191-4d75-83b4-7e20b6d7ad11\",\"a6474b44-c091-4be5-a19c-aee8f7529d72\",\"a708bf55-aff7-4cc9-baf4-cc6f7a73e0ca\",\"c092c75d-a342-4f55-b421-c00e15cb4872\",\"d770254e-cc0d-4951-8040-cb7c1fec6961\",\"daceec7d-03db-4f1b-83a3-8a3621693e47\",\"dda41f17-9d8d-4064-8ef5-fd139dc49172\",\"f96a2351-b604-43b0-a34f-54fd861edfc9\"}"
>
--
Russell Bryant
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
