Azure Application Gateway – SSl/TLS Pass-through In Multi Site Setup

The application gateway in Azure is one of key resources in exposing the applications deployed internally (in the Azure) through a secured mechanism.

What Is Application Gateway

It’s a layer-7 load balancer, with Web Application Firewall (WAF) provision. This WAF once enabled, follows the OWASP (Open Worldwide Application Security Project) policies and make sure the incoming requests are complying to it.

In this blog, we are dealing with a simple design of a web-application architecture plan in Azure. So, there is no firewall, DB etc., are show. The main aim is to convey on the SSL pass through settings in Azure application G/W.

SSL/TLS in Azure Application Gateway

The practical scenario is given below.

Scenario 1

The external traffic flows to application gateway, with http or https request. The production setup only has https setup, so it’s always better to practice the SSL flow in lower environments itself.

Scenario 2

The most important operation for SSL / TLS takes place here. There are two ways SSL can be handled in Application G/W

• Terminating the SSL communication in Application G/W itself, so that further communication downstream will be in the non encrypted mode.

• Pass the TLS communication downstream (in this case ingress in Kubernetes), so that those services will terminate the SSL and send non encrypted communication to it’s downstream.
• The preferable and most compliance standards suggestion is to have the second method of SSL termination. Because after the downstream mostly DB will be there which always should have TSL encryption enabled.

Scenario 3

The ingress in Kubernetes, where SSL termination will be happening.

Scenario 4

The ingress routes traffic to service, based on input host, which in turn gets redirected to the pod which servers the input request.

SSL Pass Through

In this example, we are taking the following resources

1. AKS – Kubernetes hosting three pods, for three applications load-balanced by Ingress (nginx is the most used ingress type). The load balancer for ingress is an internal one. Ingress serves three website hosts, and redirects the request to the appropriate service.
2. Application Gateway – Layer 7 load balancer, with one public IP mapped to three different DNS in the DNS hosting.

Scenario 1

Listeners – receives request based on the DNS mapped. As mentioned in diagram Listener-1 for website1, Listener-2 for website2 and Listener-3 for website3. For receiving https based communication, all these listeners has to be configured separately for each website with port 443.

One simple example, where the listener configured with only one sight for 443 port is shown below. The same can be repeated up to 5 websites (limitations of Application G/W), so you can have 5 different multi-site listener for a port (443, in this case).

Only “.cer” extension file of SSL certificate can be uploaded in listener setup.

Scenario 2

Routes – the route redirects the request from listener to the backend configured (which is ingress internal Load-Balancer IP), but after applying the backend settings configured.

Scenario 3

Backend settings – most important part where we have to do quite a few settings.

• Each website (listener) should have a back-end setting. This is because, we need to make sure the correct host name is passed for SSL certificate getting uploaded, for SSL verification, otherwise ingress load-balancer IP configured in back-end pool will be sent which will get failed with SSL verification. The domain host name over-writing will serve this purpose, which is discussed below.
• It should have “https” enabled.

• The root certificate (.cer) extension file has to be uploaded. After uploading once, it can be used in other back-end settings as well.
• The domain host name has to be overridden which should be corresponding to the host name given in the listener configuration. Rest of the parameters like – cookie based affinity etc., are kept default here, but can be changed according to your requirement. The “Override backend path” should be kept as “/”, unless otherwise a special requirement is needed.
• The configuration now allows SSL to go through the down-stream where the SSL termination has to be handled.

Scenario 5

SSL passing through down to AKS, which has ingress. In ingress SSL termination has to be handled, otherwise Application G/W will throw 502 – bad gateway error.

Scenario 6

Representing the setup mentioned in the previous section.

Ingress Configuration – Kubernetes

• A TLS secret has to be created with “.key” (private key) and “.crt” files of SSL certificated, provided by the certified authority. (where you would have bought the SSL). There are known methods to get “.crt” from “.pem” / “.cer” with “.key” files.
• The secret has to be mentioned in the ingress (where rules are applied) yaml. Please refer the “hosts” section where domain name and secret name are mentioned.
• This will make sure, the SSL is communicated to ingress without any issue and got terminated.

SSL – Termination In Application Gateway.

For SSL termination, upload the certificate in listener for https port (443) and route that to a backend setting with 80 port (http backend setting). This will terminate the SSL in Application G/W itself and sends un-encrypted communication downstream

• In this case you don’t need to create one listener for each host (website) and one backend setting for each listener.
• Similarly one back-end setting with http configuration should be good enough to server all requests.

• One listener with all site in multi site configuration will be good enough, because there is no need for host over-riding would be required in the backend setting as the backend will be using IP with no http.
• Back-end host name over-riding will be required, only if we have https (SSL/TLS) passthrough where SSL certificate only recognizes host name.