title: .Net Core microservices: using HTTPS on Kubernetes on Azure (AKS)
body: <p>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:</p>
  <ol>
  <li><p>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?</p>
  </li>
  <li><p>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!</p>
  </li>
  <li><p>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: <strong><a href="https://your-app.azurewebsites.net" rel="nofollow noreferrer">https://your-app.azurewebsites.net</a></strong> However when I go to the Public IP and configure a DNS label for something like:
  <strong>your-app.southcentralus.cloudapp.azure.com</strong> 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?</p>
  </li>
  <li><p>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 <strong>.cloudapp.azure.com</strong> domain? It would be cost/time prohibitive if I have to manage certificates for each of my services!</p>
  </li>
  </ol>