Hi Imesh, On Mon, Mar 14, 2016 at 10:20 AM, Imesh Gunaratne <[email protected]> wrote:
> Hi Manjula, > > On Mon, Mar 14, 2016 at 10:06 AM, Manjula Rathnayake <[email protected]> > wrote: > >> Hi Imesh, >> >> On Mon, Mar 14, 2016 at 9:56 AM, Imesh Gunaratne <[email protected]> wrote: >> >>> >>> On Sun, Mar 13, 2016 at 11:36 PM, Nishadi Kirielle <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> Currently I'm working on configuring HAProxy load balancing support for >>>> app cloud. >>>> In checking the session affinity functionality in kuberenetes, I have >>>> verified the load balancing of http traffic with HAProxy. It could be done >>>> using kubernetes contribution repo, 'service loadbalancer' [1]. >>>> >>>> In order to check the load balancing with https traffic the taken >>>> approach is SSL termination.In the scenario of app cloud, kubernetes >>>> cluster is not directly exposed and the load balancer exists within the >>>> cluster. Thus the communication between the application servers and the >>>> load balancer happens internally. Although SSL termination ends the secure >>>> connection at the load balancer, due to the above mentioned reasons, SSL >>>> termination seems to be a better solution. The reason for the use of SSL >>>> termination over SSL pass through is because of the complexity of handling >>>> a separate SSL certificate for each server behind the load balancer in the >>>> case of SSL pass through. >>>> >>>> -1 for this approach, IMO this has a major security risk. >>> >>> Let me explain the problem. If we offload SSL at the service load >>> balancer, all traffic beyond the load balancer will use HTTP and the >>> message content will be visible to anyone on network inside K8S. Which >>> means someone can simply start a container in K8S and trace all HTTP >>> traffic going through. >>> >> > >> Below is from HA Proxy documentation[1]. AFAIU, HA Proxy to backend >> server communication happens with HTTPS enabled but not validating the >> server certificate. >> > > >> verify >> <http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2-verify> >> [none|required] >> >> This setting is only available when support for OpenSSL was built in. If set >> to 'none', server certificate is not verified. In the other case, The >> certificate provided by the server is verified using CAs from 'ca-file' >> and optional CRLs from 'crl-file'. If 'ssl_server_verify' is not specified >> in global section, this is the default. On verify failure the handshake >> is aborted. It is critically important to verify server certificates when >> using SSL to connect to servers, otherwise the communication is prone to >> trivial man-in-the-middle attacks rendering SSL totally useless. >> >> IMO still there is a major problem if we are not verifying the SSL > certificate. See the highlighted text. > +1. We will attend to this once initial end to end scenario got working in App Cloud. I am +1 for using a self signed cert in pods and adding it to truststore of HA Proxy to fix above issue. thank you. > > Thanks > > >> [1]. >> http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#ssl%20%28Server%20and%20default-server%20options%29 >> >> thank you. >> >> >>> Thanks >>> >>> In configuring load balancing with SSL termination, I had to customize >>>> kubernetes haproxy.conf file template of service loadbalancer repo to >>>> support SSL termination. >>>> >>>> In order to provide SSL termination, the kubernetes services have to be >>>> annotated with >>>> serviceloadbalancer/lb.sslTerm: "true" >>>> >>>> The default approach in load balancing with service load balancer repo >>>> is based on simple fan out approach which uses context path to load balance >>>> the traffic. As we need to load balance based on the host name, we need to >>>> go with the name based virtual hosting approach. It can be achieved via the >>>> following annotation. >>>> serviceloadbalancer/lb.Host: "<host-name>" >>>> >>>> Any suggestions on the approach taken are highly appreciated. >>>> >>>> Thank you >>>> >>>> [1]. >>>> https://github.com/kubernetes/contrib/tree/master/service-loadbalancer >>>> >>>> >>> >>> >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>> WSO2 Inc: http://wso2.com >>> T: +94 11 214 5345 M: +94 77 374 2057 >>> W: http://imesh.io >>> Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> Manjula Rathnayaka >> Associate Technical Lead >> WSO2, Inc. >> Mobile:+94 77 743 1987 >> > > > > -- > *Imesh Gunaratne* > Senior Technical Lead > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: http://imesh.io > Lean . Enterprise . Middleware > > -- Manjula Rathnayaka Associate Technical Lead WSO2, Inc. Mobile:+94 77 743 1987
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
