<p>Currently, I want to introduce istio as our service-mesh framework for our microservices. I have played it sometime (&lt; 1 week), and my understanding is that Istio really provides an easy way to secure service to service communication. Much (or all?) of Istio docs/article provides an example how client and server who have istio-proxy (envoy) installed as a sidecar container, can establish secure communication using <code>mtls</code> method. </p>

<p>However, since our existing client (which I don't have any control) who consume our service (which will be migrated to use istio) doesn't have istio, I still don't understand it well how we should do it better.</p>

<ul>
<li>Is there any tutorial or example that provides my use case better? </li>
<li>How can the non-istio-based client use <code>mtls</code> for consuming our istio-based service? Think about using basic <code>curl</code> command to simulate such thing.</li>
<li>Also, I am thinking of distributing a specific service account (kubernetes, gcp iam service account, etc) to the client to limit the client's privilege when calling our service. I have many questions on how these things: gcp iam service account, istio, rbac, mtls, jwt token, etc contributes to securing our service API?</li>
</ul>

<p>Any advice?</p>

<p>You want to add a third party to your Istio mesh outside of your network via SSL over public internet?</p>

<p>I dont think Istio is really meant for federating external services but you could just have an istio ingress gateway proxy sat at the edge of your network  for routing into and back out of your application.</p>

<p><a href="https://istio.io/docs/tasks/traffic-management/ingress/" rel="nofollow noreferrer">https://istio.io/docs/tasks/traffic-management/ingress/</a></p>

<p>If you're building microservices then surely you have an endpoint or gateway, that seems more sensible to me, try Apigee or something.</p>
