Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
From: Simon Weller <sweller@ena.com.INVALID>
To: "kmoossavi@cloudops.com" <kmoossavi@cloudops.com>,
	"dev@cloudstack.apache.org" <dev@cloudstack.apache.org>,
	"wstevens@cloudops.com" <wstevens@cloudops.com>
CC: "users@cloudstack.apache.org" <users@cloudstack.apache.org>
Subject: RE: HTTPS LB and x-forwarded-for
Thread-Topic: HTTPS LB and x-forwarded-for
Thread-Index: roF4X4Cb6wvxHoaIjX55vnawYbwRL6O3o6eAgAWN2wCAA0MxAIAAA5jx
Date: Wed, 8 Nov 2017 14:12:45 +0000
Message-ID: <BN6PR02MB33316769EF8007231F48D104A9560@BN6PR02MB3331.namprd02.prod.outlook.com>
References: <1750999994.6369.1509476065042.JavaMail.zimbra@li.nux.ro>
 <CAMvtBPMCKB1KJeYw4a-tY_XHNYj+SR08v_1SEz5VsYQpzhyyuQ@mail.gmail.com>
 <270992313.1239.1509970237965.JavaMail.zimbra@li.nux.ro>,<CAD97ioeHboORsFXbdLjQZ6rCH01Esbw+3+j4Q6tLamRuSafCZA@mail.gmail.com>
In-Reply-To: <CAD97ioeHboORsFXbdLjQZ6rCH01Esbw+3+j4Q6tLamRuSafCZA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: ena.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BN6PR02MB33316769EF8007231F48D104A9560BN6PR02MB3331namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e7f4b95b-87b2-440b-ba4c-08d526b2c8ea
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 14:12:45.8403
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6dc38cd4-4d4f-4826-9649-17854289d170
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB3330
X-ENA-MailScanner-Information: Report abuse to abuse@ena.com and include the next header value
X-ENA-MailScanner-ID: E5D9F14808CE.A2342
X-ENA-MailScanner: No viruses found
X-ENA-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2,
	required 4, autolearn=not spam, BAYES_00 -1.90, DKIM_SIGNED 0.10,
	DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00,
	SPF_HELO_PASS -0.00)
X-ENA-MailScanner-From: sweller@ena.com
X-ENA-MailScanner-Watermark: 1510755168.52041@nE7ZIpxuC1lZbdGIOSFVVQ
archived-at: Wed, 08 Nov 2017 14:13:09 -0000

--_000_BN6PR02MB33316769EF8007231F48D104A9560BN6PR02MB3331namp_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

I'm assuming we would have the standard openssl version with Intel TLS offl=
oad though, right? RHEL ships their FIPS compliant version that strips all =
the acceleration out. The cpu instruction sets should be passed through fro=
m the host, so hopefully that will make a massive difference to decryption =
speeds and cpu load.

Simon Weller/615-312-6068

-----Original Message-----
From: Pierre-Luc Dion [pdion@cloudops.com]
Received: Wednesday, 08 Nov 2017, 9:00AM
To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]; Khosrow Moossavi=
 [kmoossavi@cloudops.com]; Will Stevens [wstevens@cloudops.com]
CC: users [users@cloudstack.apache.org]
Subject: Re: HTTPS LB and x-forwarded-for

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)
- 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, a=
t
> 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 leve=
l,
> > 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 v=
ia
> > 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 al=
l
> > user cases, with proper HTTP checks and similar....is impossible to do
> > IMHO.
> >
> > Some other clients, actually have internal FW appliance (i.e. multihome=
d
> > 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=E6
>

--_000_BN6PR02MB33316769EF8007231F48D104A9560BN6PR02MB3331namp_--