Trying to secure a network of microservices with a home grown solution can be difficult and confusing. This where a service mesh, such as Istio, helps. It secures both north-south traffic and east-west traffic. North-south traffic is traffic entering (ingress) and exiting (egress) the service mesh. East-west traffic is traffic within the mesh, typically service-to-service. Istio handles north-south traffic through ingress and egress gateways, and traffic routing is managed by virtual services. Istio’s Envoy proxy manages east-west traffic, running as a sidecar in the Kubernetes pod of the service it is protecting. Now let’s look at an example of these concepts applied to a small service mesh.

Exposing Services Outside of the Service Mesh

In this example, we will start with two microservices — a web client running in a NGINX web server and a Java/Spring Boot backend REST service. I describe these services in greater detail in an earlier article on  Istio Performance.

The client is a “friendly” client whom we are going to allow access to the back end service. Later, we will add a third microservice to the mesh — a malicious “enemy” web client who will be denied access to the back-end microservice. The back-end microservice, called “capitol-info”, has query and insert capabilities to a database of country capitols. The endpoints exposed by these microservices are shown in the diagram below. This diagram shows an open, unprotected service mesh architecture.

#containers #kubernetes #zero-trust #security #istio