12 Securing microservices with Istio service mesh

In chapter 6 we discussed how to secure service-to-service communication with certificates and in chapter 7 we extended that discussion to use JSON Web Tokens (JWT) to secure service-to-service communication. Then in chapters 10 and 11 we discussed how to deploy a set of microservices as Docker containers in Kubernetes and then again secure service-to-service communication with JWT over mutual Transport Layer Security (mTLS). In all of these cases each microservice by itself had to worry about doing security processing. Or in other words, each microservice embedded a set of Spring Boot libraries to do security processing. This violates one key aspect of microservices architecture, the Single Responsibility Principle,[1] under which a microservice should be performing only one particular function.

12.1   Setting up the Kubernetes deployment

12.1.1   Enabling Istio auto injection

12.1.2   Clean up any previous work

12.1.3   Deploying microservices

12.1.4   Testing end-to-end flow

12.2   Enabling TLS termination at the Istio ingress gateway

12.2.1   Deploying TLS certificates to the Istio ingress gateway

12.2.2   Deploying VirtualServices

12.2.3   Defining a permissive authentication policy

12.2.4   Testing end-to-end flow

12.3   Securing service-to-service communication with mTLS

12.4   Securing service-to-service communication with JWT

12.4.1   Enforcing JWT authentication

12.4.2   Testing end-to-end flow with JWT authentication

12.4.3   How to use JWT in service-to-service communication

12.4.4   A closer look at JSON Web Key (JWK)

12.5   Enforcing authorization

12.5.1   A closer look at the JWT

12.5.2   Enforcing Role-base Access Control

12.5.3   Testing end-to-end flow with RBAC

12.6   Managing keys in Istio

12.6.1   Key rotation via volume mounts

12.6.2   Limitations in key rotation via volume mounts

12.6.3   Key provisioning and rotation with SDS

12.7   Summary