<p>I'm trying to get mTLS between two applications in two kubernetes clusters without the way Istio does it (with its ingress gateway), and I was wondering if the following would work (for Istio, for Likerd, for Consul...).</p>

<p>Let's say we have a k8s cluster A with an app A.A. and a cluster B with an app B.B. and I want them to communicate with mTLS.</p>

<ul>
<li>Cluster A has letsEncrypt cert for nginx ingress controller, and a mesh (whatever) for its application.</li>
<li>Cluster B has self signed cert from our root CA.</li>
<li>Cluster A and B service meshes have different certificates signed by our root CA.</li>
<li>Traffic goes from the internet to Cluster A ingress controller (HTTPS), from there to app A.A. </li>
<li>After traffic gets to app A.A., this app wants to talk to app B.B.</li>
<li>Apps A.A. and B.B. have endpoints exposed via ingress (using their ingress controllers).</li>
<li>The TLS certificates are ended in the endpoints and are wildcards.</li>
</ul>

<p>Do you think the mTLS will work in this situation?</p>

<p>Basically this <a href="https://www.portshift.io/blog/secure-multi-cluster-connectivity/?fbclid=IwAR22fqPDRaEdNdj8m7G2hNl2Y7S8lpxJDf5G8eBwnDAj3hnh4S1tcp8qBQk" rel="nofollow noreferrer">blog</a> from portshift answer your question.</p>

<p>The answer is depends on how your clusters are built, because </p>

<blockquote>
  <p>Istio offers few options to deploy service mesh in multiple kubernetes clusters, more about it <a href="https://stackoverflow.com/a/60149783/11977760">here</a>.</p>
</blockquote>

<p>So, if you have Single Mesh deployment </p>

<p><img src="https://www.portshift.io/wp-content/uploads/2019/10/Istio-extension-post.png" alt="Istio extension post"></p>

<blockquote>
  <p>You can deploy a single service mesh (control-plane) over a fully connected multi-cluster network, and all workloads can reach each other directly without an Istio gateway, regardless of the cluster on which they are running.</p>
</blockquote>

<hr>

<p><em>BUT</em></p>

<hr>

<p>If you have Multi Mesh Deployment</p>

<p><img src="https://www.portshift.io/wp-content/uploads/2019/10/Istio-diagram.png" alt="A multi service mesh deployment over multiple clusters"></p>

<blockquote>
  <p>With a multi-mesh deployment you have a greater degree of isolation and availability, but it increases the set-up complexity. Meshes that are otherwise independent are loosely coupled together using ServiceEntries, Ingress Gateway and use a common root CA as a base for secure communication. From a networking standpoint, the only requirement is that the ingress gateways be reachable from one another. Every service in a given mesh that needs to be accessed a service in a different mesh requires a ServiceEntry configuration in the remote mesh.</p>
</blockquote>

<hr>

<blockquote>
  <p>In multi-mesh deployments security can become complicated as the environment grows and diversifies. There are security challenges in authenticating and authorizing services between the clusters. The local <a href="https://istio.io/docs/reference/config/policy-and-telemetry/" rel="nofollow noreferrer">Mixer</a> (services policies and telemetries) needs to be updated with the attributes of the services in the neighbouring clusters. Otherwise, it will not be able to authorize these services when they reaching its cluster. To achieve this, each Mixer needs to be aware of the workload identities, and their attributes, in neighbouring clusters  Each <a href="https://istio.io/docs/concepts/security/" rel="nofollow noreferrer">Citadel</a> needs to be updated with the certificates of neighbouring clusters, to allow mTLS connections between clusters.</p>
  
  <p>Federation of granular workloads identities (mTLS certificates) and service attributes across multi-mesh control-planes can be done in the following ways:</p>
  
  <ul>
  <li><em>Kubernetes Ingress:</em> exposing HTTP and HTTPS routes from outside the cluster to  <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">services</a>  within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. An Ingress can terminate SSL / TLS, and offer name based virtual hosting. Yet, it requires an  <a href="https://kubernetes.io/docs/concepts/services-networking/ingress-controllers" rel="nofollow noreferrer">Ingress controller</a> for fulfilling the Ingress rules</li>
  <li><em>Service-mesh gateway:</em> The Istio service mesh offers a different configuration model, <a href="https://istio.io/docs/reference/config/networking/v1alpha3/gateway/" rel="nofollow noreferrer">Istio Gateway</a>. A gateway allows Istio features such as monitoring and route rules to be applied to traffic entering the cluster. An ingress g<a href="https://istio.io/docs/reference/config/networking/v1alpha3/gateway/" rel="nofollow noreferrer">ateway</a> describes a load balancer operating at the edge of the mesh that receives incoming HTTP/TCP connections. It configures exposed ports, protocols, etc. Traffic routing for ingress traffic is configured instead using Istio routing rules, exactly the same way as for internal service requests.</li>
  </ul>
</blockquote>

<hr>

<blockquote>
  <p>Do you think the mTLS will work in this situation?</p>
</blockquote>

<p>Based on above informations </p>

<ul>
<li><p>If you have Single Mesh Deployment</p>

<p>It should be possible without any problems.</p></li>
<li><p>If you have Multi Mesh Deployment</p>

<p>It should work, but since you don't want to use istio gateway then the only option is <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">kubernetes ingress</a>. </p></li>
</ul>

<p>I hope it answer your question. Let me know if you have any more questions.</p>
