cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: HTTPS LB and x-forwarded-for
Date Thu, 09 Nov 2017 07:13:02 GMT

> Op 8 november 2017 om 14:59 schreef Pierre-Luc Dion <pdion@cloudops.com>:
> 
> 
> Same challenge here too!
> 
> Let's look at improving Load-balancing offering from cloudstack, I guest we
> should do a feature spec draft soon..,  from my perspective, doing SSL
> offload on the VR could be problematic if the VR spec if too small, and the
> default spec of the VR being 1vcpu@256MB, considering it can be the router
> of a VPC, doing VPN termination, adding HTTPS  is a bit ish... What would
> be your thought about this ?
> 
> I'd be curious to have a LB offering in ACS where it would deploy a
> redundant traefik[1] beside the VR for doing http and https Load-balancing.
> I think it would also be useful if the API of that traefik instance would
> be available from within the VPC or LBnetwork so is API would be accessible
> to other apps orchestration tools such as  kubernetes or rancher.
> 
> traefik or not, here is what I think is needed by cloudstack in the LB
> improvement:
> 
> - support http, https (X-Forwarded-For)

HAProxy also supports the PROXY protocol towards the backends. Apache 2.4.22 supports this
natively and Varnish for example can also talk PROXY.

It adds a littlebit of metadata to the connection so that the backend knows the original IP
the connection came from for example: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

Wido

> - basic persistence tuning (API already exist)
> - better backend monitoring, currently only a tcp connect validate if the
> webserver is up.
> - ssl offload
> - metric collection, more stats, maybe just export the tool status page to
> the private network.
> - Container world support, right now if you have Rancher or kubernetes
> cluster, you need to deploy your own LB solution behing mostlikely a static
> nat., If cloudstack would deploy a traefik instance, Kub or Rancher could
> reuse this instance and managed it to properly do LB between containers.
> 
> 
> What would be your prefered LB tool:
> haproxy, traefik or nginx?
> 
> CloudStack already have to code to handle SSL certs per projects and
> accounts if not mistaking because that code was added to support NetScaler
> as Load-balancer in the past. so one less thing to think about :-)
> 
> 
> [1] https://traefik.io/
> 
> 
> PL,
> 
> 
> 
> On Mon, Nov 6, 2017 at 7:10 AM, Nux! <nux@li.nux.ro> wrote:
> 
> > Thanks Andrija,
> >
> > LB outside of the VR sounds like a good idea. An appliance based on, say
> > cloud-init + ansible and so on could do the trick; alas it'd need to be
> > outside ACS.
> > I guess as users we could maybe come up with a spec for an improvement, at
> > least we'd have something the devs could look at whenever it is possible.
> >
> > Regards,
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > ----- Original Message -----
> > > From: "Andrija Panic" <andrija.panic@gmail.com>
> > > To: "dev" <dev@cloudstack.apache.org>
> > > Cc: "users" <users@cloudstack.apache.org>
> > > Sent: Thursday, 2 November, 2017 23:21:37
> > > Subject: Re: HTTPS LB and x-forwarded-for
> >
> > > We used to make some special stuff for one of the clients, where all LB
> > > configuration work is done from outside of the ACS, i.e. python script to
> > > feed/configure VR - install latest haproxy 1.5.x for transparent proxy,
> > > since client insisted on SSL termination done on backend web SSL
> > servers....
> > > Not good idea, that is all I can say (custom configuration thing) - but
> > the
> > > LB setup is actually good - transparent mode haproxy, works on TCP level,
> > > so you can see "real client IP" on the backend servers (which must use VR
> > > as the default gtw, as per default, so the whole setup works properly).
> > >
> > > I'm still looking forward to see some special support of LB inside VR via
> > > ACS - proper LB setup inside VR via GUI/API -  i.e. to enable LB
> > > provisioning SCRIPT (bash, or whatever),  where all needed
> > > install+configure can be done from client side  - otherwise covering all
> > > user cases, with proper HTTP checks and similar....is impossible to do
> > > IMHO.
> > >
> > > Some other clients, actually have internal FW appliance (i.e. multihomed
> > > VM, acting as gtw for all VMs in all networks), and haproxy instaled on
> > > this device (with NAT configured from VR to this internal FW/VM, so
> > remote
> > > IP can be seen properly) - this setup is fully under customer control,
> > and
> > > can provide any kind of special haproxy config...
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 31 October 2017 at 19:54, Nux! <nux@li.nux.ro> wrote:
> > >
> > >> Hello,
> > >>
> > >> Of the people running an LB (VR) with https backends, how do you deal
> > with
> > >> the lack of x-forwarded-for since for port 443 there's just simple TCP
> > >> balancing?
> > >>
> > >> Has anyone thought of terminating SSL in the VR instead? Ideas?
> > >>
> > >> Cheers
> > >>
> > >> --
> > >> Sent from the Delta quadrant using Borg technology!
> > >>
> > >> Nux!
> > >> www.nux.ro
> > >>
> > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> >

Mime
View raw message