cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nux! <...@li.nux.ro>
Subject Re: POLL: ACL default egress policy rule in VPC
Date Fri, 17 Nov 2017 16:39:18 GMT
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" <mail@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.uradi@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é

Mime
View raw message