[rhos-list] Quantum security group egress
Maru Newby
marun at redhat.com
Tue Jul 9 15:26:30 UTC 2013
On Jul 9, 2013, at 1:56 AM, Ofer Blaut <oblaut at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Maru Newby" <marun at redhat.com>
>> To: "Ofer Blaut" <oblaut at redhat.com>
>> Cc: "Perry Myers" <pmyers at redhat.com>, "rhos-list" <rhos-list at redhat.com>, "Robert Kukura" <rkukura at redhat.com>,
>> "Maru Newby" <mnewby at redhat.com>, "Brent Eagles" <beagles at redhat.com>, "Ryan O'Hara" <rohara at redhat.com>, "Chris
>> Wright" <chrisw at redhat.com>, "Terry Wilson" <twilson at redhat.com>
>> Sent: Monday, July 8, 2013 10:28:01 PM
>> Subject: Re: Quantum security group egress
>>
>>
>> On Jul 8, 2013, at 2:19 PM, Ofer Blaut <oblaut at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Maru Newby" <marun at redhat.com>
>>>> To: "Perry Myers" <pmyers at redhat.com>
>>>> Cc: "Ofer Blaut" <oblaut at redhat.com>, "rhos-list" <rhos-list at redhat.com>,
>>>> "Robert Kukura" <rkukura at redhat.com>, "Maru
>>>> Newby" <mnewby at redhat.com>, "Brent Eagles" <beagles at redhat.com>, "Ryan
>>>> O'Hara" <rohara at redhat.com>, "Chris Wright"
>>>> <chrisw at redhat.com>, "Terry Wilson" <twilson at redhat.com>
>>>> Sent: Monday, July 8, 2013 8:45:10 PM
>>>> Subject: Re: Quantum security group egress
>>>>
>>>>
>>>> On Jul 8, 2013, at 1:33 PM, Perry Myers <pmyers at redhat.com> wrote:
>>>>
>>>>> On 07/04/2013 07:03 AM, Ofer Blaut wrote:
>>>>>> Hi
>>>>>>
>>>>>> By default egress security group is allow all.
>>>>>>
>>>>>> http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html
>>>>>>
>>>>>> Since there are no deny actions, i expect once first egress rule is
>>>>>> applied, all other traffic will be dropped
>>>>>>
>>>>>> I have tried it with add SSH to egress still ping worked
>>>>>>
>>>>>> http://pastebin.test.redhat.com/150744
>>>>>
>>>>> Ofer,
>>>>>
>>>>> So what you're saying is that there should be a deny all rule added once
>>>>> the user adds the first real egress rule.
>>>>
>>>> If a user wants to manage egress traffic, the first step is removing the
>>>> default 'allow all egress' rule. This is by design, and there would be
>>>> need
>>>> to be a good reason (convenience is not it) for it to be changed.
>>>>
>>>>
>>>> m.
>>> Hi Maru
>>>
>>> Ingress security group works the same as CISCO ACLs and other products
>>>
>>> http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html
>>> " The Implied "Deny All Traffic" Criteria Statement
>>> At the end of every access list is an implied "deny all traffic" criteria
>>> statement. Therefore, if a packet does not match any of your criteria
>>> statements, the packet will be blocked.
>>> Note For most protocols, if you define an inbound access list for traffic
>>> filtering, you should include explicit access list criteria statements to
>>> permit routing updates. If you do not, you might effectively lose
>>> communication from the interface when routing updates are blocked by the
>>> implicit "deny all traffic" statement at the end of the access list. "
>>>
>>
>> You are correct, and the implication is that if it is only possible to create
>> a security group rule that allows traffic, not one that denies traffic.
>>
>>
>>> I didn't find any info about what should be expected in blueprints
>>
>> The purpose of security groups is described in the opening sentence in the
>> docs [1] (emphasis mine):
>>
>> "Security groups and security group rules allows administrators and tenants
>> the ability to specify the type of traffic and direction (ingress/egress)
>> that is ALLOWED to pass through a port."
>>
>>
>>>
>>> Below is an example of egress and ingress rules of default security-group ,
>>> how can tell the difference between ingress (deny all ) and egress (allow
>>> all) ?
>>> the output seems the same .
>>
>> Security groups work the same for both ingress and egress. If traffic
>> matches a security group rule, it is passed. If it does not match a rule,
>> it is dropped (default deny). Given this, the examples you have below are
>> both 'allow all', since 'deny' rules are not supported.
>>
>>
>> m.
> Hi Maru
>
> Thanks for your explanation
>
> When creating new tenant and network, new/default security group is created.
> Both ingress and egress rules contain the same values as in the example below ( please check the rule attributes ).
>
> Ingress rule is acting as deny all, and egress is as allow all.
>
> You can "see" it by checking quantum security-group-rule-show , both rules are identical (port_range_max = none, port_range_min = none , protocol = none )
>
> IMHO we should remove all default ingress rules because they are misleading
The rules are not identical. On the ingress rule, the remote_group_id field matches the id of the default security group. On the egress rule, remote_group_id is empty. A rule for which remote_group_id is set will allow traffic only from ports associated with the specified security group. This implies that the default ingress rule allows ingress traffic between VMs that are associated with the default security group, and combined with the 'allow all' egress rule, ensures that inter-VM communication is possible by default.
m.
> Thanks
>
> Ofer
>
>
>>
>> [1]:
>> http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html
>>
>>> ofer
>>>
>>>
>>> [root at puma04 ~(keystone_admin_tenant1)]$quantum security-group-rule-list
>>> +--------------------------------------+----------------+-----------+----------+------------------+--------------+
>>> | id | security_group | direction |
>>> | protocol | remote_ip_prefix | remote_group |
>>> +--------------------------------------+----------------+-----------+----------+------------------+--------------+
>>> | 80dd52fb-80b4-4a26-94ae-4e052f128fef | default | egress |
>>> | | | |
>>> | 9acac0e0-9900-4d42-8ce9-813bd80592d3 | default | ingress |
>>> | | | default |
>>> | 9bbe9a67-2b35-443b-ad3a-8338ede82fcd | default | ingress |
>>> | | | default |
>>> | abc1bfa4-0a35-482f-a8ce-4443e3444532 | default | egress | tcp
>>> | | | default |
>>> | fdb1f4c9-2260-450f-b4e7-196564870d79 | default | egress |
>>> | | | |
>>> +--------------------------------------+----------------+-----------+----------+------------------+--------------+
>>>
>>> [root at puma04 ~(keystone_admin_tenant1)]$quantum security-group-rule-show
>>> 9acac0e0-9900-4d42-8ce9-813bd80592d3
>>> +-------------------+--------------------------------------+
>>> | Field | Value |
>>> +-------------------+--------------------------------------+
>>> | direction | ingress |
>>> | ethertype | IPv4 |
>>> | id | 9acac0e0-9900-4d42-8ce9-813bd80592d3 |
>>> | port_range_max | |
>>> | port_range_min | |
>>> | protocol | |
>>> | remote_group_id | b0dc4c19-cb7f-4d08-a2d4-e315a4169f09 |
>>> | remote_ip_prefix | |
>>> | security_group_id | b0dc4c19-cb7f-4d08-a2d4-e315a4169f09 |
>>> | tenant_id | fdf9ecab37d340e98b915bcd32504621 |
>>> +-------------------+--------------------------------------+
>>> [root at puma04 ~(keystone_admin_tenant1)]$quantum security-group-rule-show
>>> 80dd52fb-80b4-4a26-94ae-4e052f128fef
>>> +-------------------+--------------------------------------+
>>> | Field | Value |
>>> +-------------------+--------------------------------------+
>>> | direction | egress |
>>> | ethertype | IPv4 |
>>> | id | 80dd52fb-80b4-4a26-94ae-4e052f128fef |
>>> | port_range_max | |
>>> | port_range_min | |
>>> | protocol | |
>>> | remote_group_id | |
>>> | remote_ip_prefix | |
>>> | security_group_id | b0dc4c19-cb7f-4d08-a2d4-e315a4169f09 |
>>> | tenant_id | fdf9ecab37d340e98b915bcd32504621 |
>>> +-------------------+--------------------------------------+
>>>
>>>
>>>>
>>>>>
>>>>> Otherwise the egress rules serve no purpose really...
>>>>>
>>>>> That seems to make sense to me. What do the neutron folks think?
>>>>>
>>>>> Perry
>>>>
>>>>
>>
>>
More information about the rhos-list
mailing list