[rhos-list] Quantum security group egress

Ofer Blaut oblaut at redhat.com
Tue Jul 9 05:56:07 UTC 2013



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

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