Open Stack

Hi Tomoe,

Here is the implementation for allow all egress if there are no egress rule.
https://github.com/openstack/quantum/blob/master/quantum/db/securitygroups_rpc_base.py#L227

Internally, the implementation is default deny. I'm adding all all
egress traffic iptables rule here.
If this is not working well, could you report a bug reprot on launchpad?

Thanks
Nachi


2013/2/26 Dan Wendlandt <dan at nicira.com>:
> Hi Tomoe,
>
> Yes, my understanding of what Amazon does is that each VPC security group is
> automatically configured with an explicit "allow all outbound" rule.  I
> assume Amazon did this so that that VPC groups were implicitly backward
> compatible with non-VCP security groups, which perform no egress filtering.
> However, if you remove this rule and have a truly empty egress group, all
> packets will be dropped, which makes the default-deny semantics symmetric
> across both ingress + egress rules.
>
> I personally like the trade-off amazon made here and I think it makes sense
> to do something similar in Quantum.
>
> dan
>
> On Tue, Feb 26, 2013 at 3:29 AM, Tomoe Sugihara <tomoe at midokura.com> wrote:
>>
>> Hi quantum devs,
>>
>> I was looking into Quantum Security Groups feature and I have some
>> questions regarding default behavior for egress processing.
>>
>> From the slide[1] linked form the BP and the document[2], it sounds like
>> the following:
>>
>>  - by default, all the egress traffic would be allowed
>>  - once you have a egress rule, the rule processing becomes white list,
>> meaning traffic that doesn't match on the rules would be dropped.
>>
>> This actually sounds similar to what Amazon VPS SG document[3], although
>> their implementation doesn't match on the statement in the doc, which I'll
>> get to it shortly.
>>
>> If I understand the spec correctly, when I remove the last egress rule
>> from all the SGs bound to a port, the default behavior should change from
>> DROP to ALLOW. Symmetrically, when I add a first egress rule in any of the
>> SGs to which a VM is bound, the default behavior should change from ALLOW to
>> DROP. Am I interpreting this right?
>> However, I couldn't find a part to implement this. In fact, this
>> processing would be annoying if you have thousands of ports referring to
>> multiple SGs because, for each port, you would have to count numbers of
>> egress rules for all the SGs, and depending on the count, you would have to
>> change the default behavior.
>>
>> Then, I took a look at Amazon VPC security groups in the console. Contrary
>> to their online doc, their implementation seems more intuitive or explicit
>> like this:
>>
>> - When you create a SG, you get a (default) visible outbound rule that
>> allows everything
>> - When you add/delete egress rules to the SG, the default rule is not
>> affected.
>>
>> Basically, in VPC SG outbound behavior, just as same as the inbound, the
>> default is DROP. There's no implicit default behavior.
>> You merely get the default rule to allow everything for default SG, as
>> well as when you create another SG.
>>
>> So, I'm wondering what the right behavior for Quantum SG. To me, amazon
>> style seems easy to understand for user's perspective and easy to implement.
>> And, I now slightly remember that there was a discussion about having amazon
>> compatibility flag in OS summit.
>>
>> I'd appreciate any comments.
>>
>> Thanks,
>> Tomoe
>>
>>
>> [1]
>> http://docs.openstack.org/trunk/openstack-network/admin/content/securitygroups.html
>> [2]:
>> http://www.slideshare.net/delapsley1/20120417-osdesignsummitsecuritygroupsdlapsleyfinal
>> , slide, 13.
>> [3]:
>> http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>