[rhos-list] Quantum security group egress

Maru Newby marun at redhat.com
Mon Jul 8 19:28:01 UTC 2013


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. 

[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