Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Message-ID: <570B3D53.5040202@gmail.com>
Date: Sun, 10 Apr 2016 22:59:47 -0700
From: ilya <ilya.mailing.lists@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Request for comments : VPC Inline LoadBalancer (new
 plugin)
References: 
 <CAEGgDnaJviLWsm_H6RpYD5k4-j+De3a=Ge=U_P+bWS=RQThqrw@mail.gmail.com>
	<56F419C0.4080904@gmail.com>
	<MA1PR01MB01201E0F622576598D5E2C4289830@MA1PR01MB0120.INDPRD01.PROD.OUTLOOK.COM>
 <CAJVWTBK3+d7yAj9BfEXEVH6f-PJSUJ7D4SerasW4WdbK_hLh_A@mail.gmail.com>
In-Reply-To: 
 <CAJVWTBK3+d7yAj9BfEXEVH6f-PJSUJ7D4SerasW4WdbK_hLh_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Kris and Nick

Noticed an update in the FS:

>> The VPC Inline LB appliance therefore is a regular System VM, exactly
the same as the Internal LB appliance today. Meaning it has 1 guest nic
and 1 control (link-local / management) nic.


This should be ok. The premise behind my concern was - if LB Inline VM
was to get hack (re: SSL HeartBlead) and intruder has root level
privileges, he could try to go further in the network in an attempt to
get access to MGMT layer. Since we have link-local - its limited to 1
hypervisor only.

Assuming iptables/firewall on hypervisor blocks incoming traffic from VR
link local address - we should be ok. I guess i need to double check on
this.

Regards
ilya


On 4/10/16 1:26 PM, Kris Sterckx wrote:
> Hi all
> 
> 
> Thanks for reviewing the FS. Based on the received comments I clarified
> further in the FS that the Vpc Inline LB appliance solution is based on the
> Internal LB appliance solution, only now extended with secondary IP's and
> static NAT to Public IP.
> 
> I also corrected the "management" nic to "control" nic. The text really
> meant eth1, i.e the link-local nic on KVM.
> 
> Pls find the updated text :
> 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340894
> 
> Architecture and Design description
> 
> We will introduce a new CloudStack network plugin “VpcInlineLbVm” which is
> based on the Internal LoadBalancer plugin and which just like the Internal
> LB plugin is implementing load balancing based on at-run-time deployed
> appliances based on the VR (Router VM) template (which defaults to the
> System VM template), but the LB solution now extended with static NAT to
> secondary IP's.
> 
> The VPC Inline LB appliance therefore is a regular System VM, exactly the
> same as the Internal LB appliance today. Meaning it has 1 guest nic and 1
> control (link-local / management) nic.
> 
> With the new proposed VpcInlineLbVm set as the Public LB provider of a VPC,
> when a Public IP is acquired for this VPC and LB rules are configured on
> this public IP, a VPC Inline LB appliance is deployed if not yet existing,
> and an additional guest IP is allocated and set as secondary IP on the
> appliance guest nic, upon which static NAT is configured from the Public IP
> to the secondary guest IP.  (See below outline for the detailed algorithm.)
> 
> *In summary*, the VPC Inline LB appliance is reusing the Internal LB
> appliance but its solution now extended with Static NAT from Public IP's to
> secondary (load balanced) IP's at the LB appliance guest nic.
> 
> 
> Hi Ilya,
> 
> Let me know pls whether that clarifies and brings new light to the
> questions asked.
> 
> Can you pls indicate, given the suggested approach of reusing the appliance
> mechanism already used for Internal LB, whether this addresses the concern
> or, when it doesn't, pls further clarify the issue seen in this approach.
> 
> Thanks!
> 
> 
> Hi Sanjeev, to your 1st question:
> 
> Will this LB appliance be placed between guest vm's and the Nuage VSP
> provider(Nuage VSP and lb appliance will have one nic in guest network)?
> 
>> Please note that the LB appliance is a standard System VM, having 1 nic
> in Guest network and 1 nic in Control. There is as such no relation between
> this Appliance and the Nuage VSP.
> 
> In the case where Nuage VSP is the Connectivity provider, the appliance has
> a guest nic in a Nuage VSP managed (VXLAN) network, like all guest VM's
> would have. But that is dependent on the provider selection.
> 
> In the specific case of Nuage VSP, publicly load balanced traffic will
> indeed flow as : (pls read-on to your 2nd question also) :
>     -> incoming traffic on Public IP  (Nuage VSP managed)
>     -> .. being Static NAT'ted to Secondary IP on Vpc Inline LB VM
>  (NAT'ting is Nuage VSP managed)
>     -> .. being load balanced to real-server guest VM IP's  (Vpc Inline LB
> VM appliance managed)
>     -> .. reaching the real-server guest VM IP
> 
> To your 2nd question:
> 
> Is there any specific reason for traffic filtering on lb appliance instead
> of Nuage VSP ? If we configure firewall rules for LB services on the Nuage
> VSP instead of the inline lb appliance (iptable rules  for lb traffic),
> traffic can be filtered on the Nuage VSP before Natting?
> 
>> Please note that the generic Static NAT delegation is applicable : the
> realization of the Static NAT rules being set up, depends on the Static NAT
> provider in the VPC offering. In case Nuage VSP is the provider for Static
> NAT (which it would be in the case of a Nuage SDN backed deployment), the
> NAT’ting is effectively done by the Nuage VSP.  If anyone else is the
> provider, than this provider is being delegated to.
> 
> Thanks!
> 
> 
> Let me know whether this overall clarifies.
> 
> Pls don't hesitate to ask and further questions.
> 
> 
> Best regards,
> 
> 
> Kris Sterckx
> 
> 
> 
> On 25 March 2016 at 07:08, Sanjeev Neelarapu <
> sanjeev.neelarapu@accelerite.com> wrote:
> 
>> Hi Nick Livens,
>>
>> I have gone through the FS and following are my review comments:
>>
>> 1. Will this LB appliance be placed between guest vms and the Nuage VSP
>> provider(Nuage VSP and lb appliance will have one nic in guest network)?
>> 2. Is there any specific reason for traffic filtering on lb appliance
>> instead of Nuage VPS ? If we configure firewall rules for LB services on
>> the Nuage VSP instead of the inline lb appliance (iptable rules  for lb
>> traffic), traffic can be filtered on the Nuage VSP before Natting?
>>
>> Best Regards,
>> Sanjeev N
>> Chief Product Engineer, Accelerite
>> Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>>
>>
>> -----Original Message-----
>> From: ilya [mailto:ilya.mailing.lists@gmail.com]
>> Sent: Thursday, March 24, 2016 10:16 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Request for comments : VPC Inline LoadBalancer (new
>> plugin)
>>
>> Hi Nick,
>>
>> Being fan of SDN, I gave this proposal a thorough read.
>>
>> I do have only 1 comment - that you can perhaps can use to reconsider:
>>
>> "Each appliance will have 2 nics, one for management, and one in the guest
>> network. "
>>
>> In general, 2 nics - one going to management and one going to guest - is
>> looked very negatively upon by internal InfoSec team. This implementation
>> will make an LB non-compliant from SOX or PCI perspective.
>>
>> Proposed alternate solution:
>> Deploy a VM with 2 NICs but put them both on the same guest network (I
>> believe the support 2 NICs on the *same* guest network has already been
>> submitted upstream). 1 NIC for MGMT and 1 NIC for GUEST.
>>
>> Using SDNs ability to restrict communication flow (openvswitch or what
>> not), only allow specific connections from CloudStack MS to Inline LB on
>> MGMT NIC. You will need to block all external GUEST communication to MGMT
>> NIC and only make it talk to CloudStack MS on specific ports.
>>
>> This approach should preserve the internal compliance and wont raise any
>> red flags.
>>
>> Perhaps reach out to a client who requested this feature and ask what they
>> think, maybe they have not thought this through.
>>
>> Regards
>> ilya
>>
>> PS: If we were to entertain the idea of InLine LB, we would most likely
>> ask for approach mentioned above.
>>
>>
>>
>>
>> On 3/24/16 1:18 AM, Nick LIVENS wrote:
>>> Hi all,
>>>
>>> I'd like to propose a new plugin called the "VPC Inline LB" plugin.
>>> The design document can be found at :
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340
>>> 894
>>>
>>> Looking forward to hear your reviews / thoughts.
>>>
>>> Thanks!
>>>
>>> Kind regards,
>>> Nick Livens
>>>
>>
>>
>>
>> DISCLAIMER
>> ==========
>> This e-mail may contain privileged and confidential information which is
>> the property of Accelerite, a Persistent Systems business. It is intended
>> only for the use of the individual or entity to which it is addressed. If
>> you are not the intended recipient, you are not authorized to read, retain,
>> copy, print, distribute or use this message. If you have received this
>> communication in error, please notify the sender and delete all copies of
>> this message. Accelerite, a Persistent Systems business does not accept any
>> liability for virus infected mails.
>>
>