I'm in the process of containerizing various .NET core API projects and running them in a Kubernetes cluster using Linux. I'm fairly new to this scenario (I usually use App Services with Windows) and a questions regarding best practices regarding secure connections are starting to come up:
Since these will run as pods inside the cluster my assumption is that I only need to expose port 80 correct? It's all internal traffic managed by the service and ingress. But is this a good practice? Will issues arise once I configure a domain with a certificate and secure traffic starts hitting the running pod?
When the time comes to integrate SSL will I have have to worry about opening up port 443 on the containers or managing any certificates within the container itself or will this all be managed by Ingress, Services (or Application Gateway since I am using AKS)? Right now when I need to test locally using HTTPS I have to add a self-signed certificate to the container and open port 443 and my assumption is this should not be in place for production!
When I do deploy into my cluster (I'm using AKS) with just port 80 open and I assign a LoadBalancer service I get a Public IP address. I'm used to using Azure App Services where you can use the global Miscrosoft SSL certificate right out of the box like so: https://your-app.azurewebsites.net However when I go to the Public IP and configure a DNS label for something like: your-app.southcentralus.cloudapp.azure.com It does not allow me to use HTTPS like App Services does. Neither does the IP address. Maybe I don't have something configured properly with my Kubernetes instance?
Since many of these services are going to be public facing API endpoints (but consumed by a client application) they don't need to have a custom domain name as they won't be seen by the majority of the public. Is there a way to leverage secure connections with the IP address or the .cloudapp.azure.com domain? It would be cost/time prohibitive if I have to manage certificates for each of my services!
It depends on where you want to terminate your TLS. For most use cases, the ingress controller is a good place to terminate the TLS traffic and keep everything on HTTP inside the cluster. In that case, any HTTP port should work fine. If port 80 is exposed by Dotnet core by default then you should keep it.
You are opening port 443 locally because you don't have the ingress controller configured. You can install ingress locally as well. In production, you would not need to open any other ports beyond a single HTTP port as long as the ingress controller is handling the TLS traffic.
Ideally, you should not expose every service as Load Balancer. The services should be of type ClusterIP, only exposed inside the cluster. When you deploy an ingress controller, it will create a Load Balancer service. That will be the only entry point in the cluster. Ingress controller will then accept and route traffic to individual services by either hostname or paths.
Let's Encrypt is a free TLS certificate signing service that you can use for your setup. If you don't own the domain name, you can use https-01 challenge to verify your identity and get the certificate. Cert Manager project makes it easy to configure Let's Encrypt certificates in any k8s clusters.
kubectl or helm3)Sidebar: If you are using Application Gateway to front your applications, consider using Application Gateway Ingress Controller