[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