Introducing Istio Service Mesh for Microservices, 2nd Edition

Chapter 7. Security

More modern cloud native application architecture may have a number of independent development teams, executing at independent sprint intervals, deploying new capabilities at a weekly or daily pace, and responsible for their own “App Ops”—their production readiness. Istio’s mission is to enable cross-cutting concerns across a series of microservices that make up the overall application, ensuring some level of consistency across all these independent services. One key capability of Istio is its ability to apply security constraints across the application with zero impact to the actual programming logic of each microservice. With the sidecar istio-proxy in place, you are applying these constraints at the network level between the services that comprise the application.

Even the super-simple application explored in this book, where the customer service/microservice calls preference which calls recommendation, exposes a number of possible areas where service mesh level security constraints can be applied.

In this chapter, we will explore Istio’s mTLS, Mixer Policy, and RBAC capabilities.

mutual Transport Layer Security (mTLS)

mTLS provides encryption between sidecar-injected, istio-enabled services. By default, traffic among our three services of customer, preference, and recommendation is in “clear text” as they just use HTTP. This means that another team, with access to your cluster, could deploy their own service and attempt to sniff the traffic flowing through ...