<p>Assume an application consisting of different web services implemented with ASP.NET Core, each of which is deployed as a Pod in a Kubernetes cluster (AKS to be exact). Now, suppose I want to secure the cluster-internal communication between those services via HTTPS. This requires me to:</p>
<ol>
<li>get TLS certificates for each of the services,</li>
<li>have the Pods trust those TLS certificates (or, rather, the signing CA), and</li>
<li>rotate the certificates when their validity period ends.</li>
</ol>
<p>What I've already learned:</p>
<ul>
<li><a href="https://stackoverflow.com/a/48168572/62838">This StackOverflow answer</a> indicates that this adds a lot of complexity and discourages going that route. Nevertheless, I'd like to know what such a setup would comprise.</li>
<li>Projects such as <em>LettuceEncrypt</em> allow to automate most of the steps 1 and 3 above. You only need a CA that implements the ACME protocol.</li>
<li>The <a href="https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/" rel="nofollow noreferrer">Kubernetes docs (&quot;Managing TLS in a cluster&quot;)</a> mention a Kubernetes API which uses a <em>&quot;protocol that is similar to the ACME draft&quot;</em> to manage CSRs.</li>
<li>However, in the docs, they're doing all the work manually (setting up a local CA, issuing CSRs manually, signing the CSRs manually using the local CA, all via the cfssl tools) that I'm wondering why on earth I would actually want to use those APIs. What are they doing for me besides storing CSRs as Kubernetes resources?</li>
<li>The docs also mention that Kubernetes clusters already include a root CA that one could use for the purpose of issuing TLS certificates for Pods, but don't explain <em>how</em> one would do so: &quot;<em>It is possible to configure your cluster to use the cluster root CA for this purpose, but you should never rely on this.</em>&quot;</li>
<li>The quote above seems to suggest and warn against using the cluster root CA at the same time. Why the warning, wouldn't it simplify things a lot if we could use an existing CA?</li>
</ul>
<p>In my mind, this could be really simple: Just set up Kestrel with <em>LettuceEncrypt</em>, configure it against the cluster root CA, and have all the Pods trust that CA (by importing the corresponding certificate as a trusted root).</p>
<p>Is it that simple? Or what am I missing?</p>
<p><strong>Update 2022-07-26:</strong> Note that I need to support Windows containers.</p>

<p>For this purpose you should use <a href="https://www.cloudflare.com/en-gb/learning/access-management/what-is-mutual-tls/" rel="nofollow noreferrer">mTLS</a>. To archive this with an AKS Cluster you can easily active the <a href="https://learn.microsoft.com/en-us/azure/aks/open-service-mesh-about" rel="nofollow noreferrer">Open Service Mesh Add-On</a>. With OSM enabled, you can now encrypt communications between service endpoints deployed in the cluster. The cool thing is the the OSM Add-on integrates with <a href="https://learn.microsoft.com/en-us/azure/aks/open-service-mesh-integrations#metrics-observability" rel="nofollow noreferrer">Azure Monitor</a>.</p>
<p><a href="https://release-v1-0.docs.openservicemesh.io/docs/demos/ingress_k8s_nginx/#https-ingress-mtls-and-tls" rel="nofollow noreferrer">Here</a> an example to do mTLS with ingress-nginx :</p>
<blockquote>
<p>To proxy connections to HTTPS backends, we will configure the Ingress
and IngressBackend configurations to use https as the backend
protocol, and have OSM issue a certificate that Nginx will use as the
client certificate to proxy HTTPS connections to TLS backends. The
client certificate and CA certificate will be stored in a Kubernetes
secret that Nginx will use to authenticate service mesh backends.</p>
</blockquote>
