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é
