<p>Say I have several services in kubernetes. And I have one entry point to the cluster, it's a public facing service that is meant to validate the JWT token (from AWS cognito).</p>
<p>The entry point routes the request to an internal service, and that in turn usually makes more requests to other internal services.</p>
<p>My question is: is it enough to validate the JWT only once and make other communications without any form of authentication, just passing the user id (or any other data needed)? Or do I need to have some form of authentication when making http requests between services? if so, which? should I validate the JWT again? should I have server certificates or something like that?</p>

Moshe Shaham
<p>Posted a community wiki answer for better visibility. Feel free to expand it.</p>
<hr />
<p>As David Szalai’s comment mentioned, it depends on your security and project requirements:</p>
<blockquote>
<p>If you go with a zero-trust model inside k8s, you can use mTLS with a service mesh between services. Passing JWTs is also good if you need to propagate user-auth info to different services.</p>
</blockquote>
<blockquote>
<p>In the current (project) we’ll use mTLS with a service mesh, and send JWTs along with requests where the receiver needs info about user, and parse/validate it there again.</p>
</blockquote>
<p>If you apps do not have built-in authentication / authorization mechanisms you may try Istio - check these articles:</p>
<ul>
<li><a href="https://istio.io/latest/docs/concepts/security/" rel="nofollow noreferrer">Istio documentation - Security</a></li>
<li><a href="https://medium.com/intelligentmachines/istio-jwt-step-by-step-guide-for-micro-services-authentication-690b170348fc" rel="nofollow noreferrer">Istio &amp; JWT: Step by Step Guide for Micro-Services Authentication</a>.</li>
</ul>
<p>Also check these articles about authentication in Kubernetes:</p>
<ul>
<li><a href="https://kubernetes.io/docs/reference/access-authn-authz/authentication/" rel="nofollow noreferrer">Kubernetes Docs - Authenticating</a></li>
<li><a href="https://learnk8s.io/microservices-authentication-kubernetes" rel="nofollow noreferrer">Authentication between microservices using Kubernetes identities</a></li>
</ul>
<p><strong>EDIT:</strong></p>
<p><em>Why?</em></p>
<p>In security, <a href="https://wso2.com/blogs/thesource/securing-microservices-in-a-zero-trust-environment/" rel="nofollow noreferrer">we say</a>:</p>
<blockquote>
<p>It’s a common principle in security that the strength of a given system is only as strong as the strength of its weakest link.</p>
</blockquote>
<p>This article - <a href="https://cloud.google.com/blog/products/networking/the-service-mesh-era-securing-your-environment-with-istio" rel="nofollow noreferrer">The service mesh era: Securing your environment with Istio</a>  mentions some possible attacks that can be done in insecure system, like man-in-the middle attacks and replayed attacks:</p>
<blockquote>
<p>An approach to mitigate this risk is to ensure that peers are only authenticated using non-portable identities.  <a href="https://cloud.google.com/istio/docs/istio-on-gke/installing#choose_a_security_option" rel="nofollow noreferrer">Mutual TLS authentication</a>  (mTLS) ensures that peer identities are bound to the TLS channel and cannot be replayed. It also ensures that all communication is encrypted in transit, and mitigates the risk of man-in-the middle attacks and replay attacks by the destination service. While mutual TLS helps strongly identify the network peer, end user identities (or identity of origin) can still be propagated using bearer tokens like JWT.</p>
</blockquote>
<blockquote>
<p>Given the proliferation of threats within the production network and the increased points of privileged access, it is increasingly necessary to adopt a zero-trust network security approach for microservices architectures. This approach requires that all accesses are strongly authenticated, authorized based on context, logged, and monitored … and the controls must be optimized for dynamic production environments.</p>
</blockquote>
<p>Without adding additional security layers (like mTLS and service mesh in a cluster), we are assuming that communication between microservices in the cluster is done in fully trusted network, <a href="https://wso2.com/blogs/thesource/securing-microservices-in-a-zero-trust-environment/" rel="nofollow noreferrer">so they can give an attacker possibility to exploit business assets via network</a>:</p>
<blockquote>
<p>Many microservices deployments today, mostly worry about the edge security by exposing the microservices via APIs and protecting those with an API gateway at the edge. Once a request passes the API gateway, the communications among microservices assume a trusted network, and expose endless possibilities to an attacker gaining access to the network to exploit all valuable business assets exposed by the microservices.</p>
</blockquote>
