<p>In some hosting environments/configurations, the network traffic between pods (applications) may traverse the public Internet. As a result, I'd like to secure the communication between the pods.</p>

<p>For example, I have the following structure:</p>

<p>Service_A - edge service in my product and provides access to my API to external users via public IP.</p>

<p>Service_B and Service_C - microservices that has ClusterIP(s).</p>

<p>As I understand I can secure traffic user&lt;-> Service_A by using Ingress controller with ssl certificate.</p>

<p>But how should I secure Service_A&lt;->Service_B communication? Create additional ingress services to wrap microservices? Are there any best practices for such cases?</p>

<p>One detail: microservices use gRPC for communication.</p>

<p>Thanks</p>

<p>A simple, generic solution that I like is to run a reverse-proxy (such as nginx) in each pod. All of your app containers will listen on localhost or unix sockets, and the ssl proxy will terminate external HTTPS connections. This makes it easy to audit your SSL config across all your apps, since every connection is terminated by the same nginx config.</p>

<p>Certificate distribution is the primary challenge with this approach. For external services, you can use LetsEncrypt to generate certs. For internal services, you'll need a private CA that is trusted by your ssl-proxy. You can mount the CA cert in a config-map at runtime. You'd then generate a cert per app or per-pod, and mount that as a Secret consumed in the ssl-proxy container.</p>

<p>If this sounds like too much work, you might want to look at <a href="https://github.com/istio/istio" rel="noreferrer">https://github.com/istio/istio</a>, which aims to automate the cluster CA role, and the provision of per-pod certificates.</p>
