Using HTTPS application Endpoint with Azure Container Apps

Question

From the Azure Container Apps documentation it is clear that for client requests TLS termination happens at ingress (Envoy proxy with ingress type HTTP) and ingress will make a new connection to the container app on the target port. If my application inside a container app is using a HTTPS endpoint, how will envoy ingress make a TLS connection with my container App?

I could not find any configuration option where I can define/govern TLS parameters for a connection between Envoy Ingress (HTTP) and a container app. For example, if I want to make a certificate authority trusted with Envoy, how could I do that?

I'd like to obtain configuration parameters, either through Azure portal or Azure CLI, to govern the connection between Envoy HTTP ingress and a container app.

Answer 1

Be considerate about what you mean by this -

If my application inside a container app is using an HTTPS endpoint, how will envoy ingress make a TLS connection with my container App?

If you are testing your application locally, with a self-signed cert, and using HTTPS, this differs from calling it an HTTPS endpoint when it runs on port 80 in the Azure container. For example, Dotnet Core automatically generates a self-signed dev cert and serves the traffic on HTTPS localhost.

In summary, to terminate the SSL at the application server origin and not at the proxy -

You must run the application server itself with an SSL certificate on port 443 and point the proxy to it. The proxy then works as an SSL passthrough.

To ensure you absolutely want to do what you are asking, here are the 3 common types of SSL Termination:

3 Common Types of SSL Termination

In most cases, you could do #1. Note: Red is HTTP and Green is HTTPS

Type1 - SSL Termination at the Proxy or Load Balancer

Even though the traffic from the Proxy to the Container is served over HTTP, it is considered reasonably secure because the traffic after the Load Balancer/Proxy lives in your isolated VPC/VNet. It's also the only way in many serverless environments. That's the option you are seeing the most documentation.

TYPE2 - SSL Termination at the Container (Reverse Proxy)

This is also very common (and cost-effective) if you don't want to use a CSP-provided proxy or Load Balancer. You can run your Application Containers behind a Reverse Proxy like Nginx. The conf files of Nginx can terminate the SSL for you.

TYPE3 - SSL Termination at the Application

It is uncommon and mostly used in specific use cases, such as when using naked Azure VMs (or AWS EC2), managing ports on the host, and not wanting to go with Type 1 or Type 2. Think of cases when you need to revoke the certs, or renew them, or auto-scale the applications.

Note: Also, for Type 2 and Type 3, (technically) you don't need to use the Proxy if you don't have a need.

How to Terminate the SSL at the Application Server Origin

Below are the architecture/application level changes that you will need to consider -

Point 1 - Changes in your Application Server (code):

The steps to load the cert inside the application can differ depending on what platform/server is running inside the container. For example, if it's an Express server, you can do something like How do I setup a SSL certificate for an express.js server?. It's not clear to me what's your platform, but you can find similar examples for C#, Python, etc.

Point 2 - Update the container listening PORT:

You'll need to run your application server with SSL for this to work. Then, instead of listening to your container on port 80, listen to 443. Also, when you run on 443, the appserver must start with the cert + private key (also sometimes with CA chain as well).

Point 3 - Use a Globally Trusted Certificate:

A self-signed cert won't work. You can use LetsEncrypt (free; there are some other options as well.) to make it a trusted cert (and not self-signed). You can also generate the SSL from any other provider (paid) and start the server using it. So long as it's a globally trusted CA, it will work as expected.

IMPORTANT: It's unsafe to embed the Cert + Pvt Key in the application code or container image. Load them via env variables or mount through docker volume etc.

As you can notice, if you horizontally scale the application containers, every instance must have these certifications. Otherwise, the specific calls to those instances would fail, and you will see intermittent issues.

Also, if you are using Azure Containers, you might need to purchase the SSL cert because managing the locations using LetsEncrypt, etc. would be very tricky and not fun. These are short-lived certs and your application must always point to the latest.