Ok, good enough for me. I vote for option 3 as well then.
-- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Rene Moser" <m...@renemoser.net> > To: "dev" <dev@cloudstack.apache.org> > Sent: Friday, 17 November, 2017 09:22:24 > Subject: Re: POLL: ACL default egress policy rule in VPC > Hi > > On 11/16/2017 11:14 AM, Nux! wrote: >> 4. I think Jayapal's reply deserves more attention. >> >> See below. >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >>> From: "Jayapal Uradi" <jayapal.ur...@accelerite.com> >>> To: "dev" <dev@cloudstack.apache.org> >>> Sent: Tuesday, 14 November, 2017 05:12:52 >>> Subject: Re: POLL: ACL default egress policy rule in VPC >> >>> Hi Rene, >>> >>> Please look at my inline comments. >>> Let me add some context for the VPC egress/ingress rules behavior. >>> >>> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows. >>> >>> 1. Default egress is ALLOW and ingress is DROP. >>> a. When a rule is added to egress then that particular rule traffic is >>> allowed >>> and rest is blocked in egress. > > This works as designed in 4.5. > > However, from a user perspective, if we have an "allow all" to egress, a > user would add a drop for a single port, but then anything else is also > blocked. The current implementation does not determine, if the rule > added is allow or blocked. > >>> b. When a rule is added to ingress then that particular rule traffic is >>> allowed >>> and rest is blocked in egress. >>> >>> After 4.5 ACL lists and ACL items feature is introduced there we have >>> ‘default >>> allow’ and ‘default deny’ ACLs. User can also >>> create a custom acl. In ACL feature we can add mix of allow and deny rules >>> and >>> the ordering of rules is maintained. > > "default allow" and "default deny" already exists in 4.5 as well. > >>> 1. when ‘default allow’ is selected while creating the vpc tier >>> By default traffic is ALLOWED and rules can be added to ALLOW/DENY the >>> traffic >>> After adding the rules there will be ACCEPT at the end >>> 2. when ‘default deny’ is selected while creating the vpc tier >>> By default traffic is DENY and rules can be added to DENY/ALLOW the >>> traffic. >>> After adding the rules there will be DROP at the end > > Makes sense, > >>> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there. >>> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add >>> rules for allow/deny rules. > > This works as designed. H > > owever, the issue I see here is that the behaviour for exising rules > changed. This can potentially lead to a security hole. In 4.5 we had an > implicit "block all egress when one rule", after 4.5 we have no such rule. > > One can arg for or against this "behaviour". The choice should be up to > a cloudstack admin, and it would be best if this can be configured. That > is why using the egressdefaultpolicy makes sense. > >>> >>> If you see behavior other than above then there will be bug. >>> >>> Currently in VPC egress behavior is controlled from the ACLs. If include >>> ‘egressdefaultpolicy’ then there will be confusion. > > I don't see why there should be any confusion at all. If you would like > to keep the behaviour currently in 4.9, you just set > egressdefaultpolicy=true. voila. > >>> What I feel is that current VPC ACLs are flexible enough to configure the >>> required behavior. > > It is flexible but the default has changed. a cloudstack admin should > have the choice. > > René
