Using Istio Service Mesh to Manage and Secure Microservices

Current development trends strongly rely on microservice architectures and cloud deployments. Dev teams must use microservices to architect for portability while Ops teams must manage large hybrid and multi-cloud deployments.

Kubernetes plays a key role in supporting current microservice/cloud architecture trends, and Istio lets you connect, secure, control and observe microservices.

And that’s true for the ProTego toolkit, which is based on a microservice architecture consisting of several components deployed on Kubernetes, using either On-Prem or Hybrid On-Cloud / On-Prem strategies, with Istio used for securely interconnecting services.

Why a Service Mesh and Istio?

The term service mesh is used to describe a network of microservices and the interactions between them. Requirements for a service mesh can include discovery, load balancing, failure recovery, metrics and monitoring. A service mesh may also include complex operational requirements. Istio makes it easy to create a network of deployed services with few or no code changes in the application.

Istio is enabled for an application by deploying a sidecar proxy that intercepts all network traffic (Data Plane). Then configuration is applied (Control Plane) in order to manage options such as:

  • Automatic load balancing,
  • Fine-grained control of traffic,
  • A pluggable policy layer and configuration API,
  • Automatic metrics, logs and traces, and
  • Secure service-to-service communication.

Traffic Management

Istio’s traffic management features let you control the flow of traffic between services. They provide out of the box typical distributed systems features that help make your application more robust. Features like circuit breakers, timeouts, retries and failure recovery can be configured. Istio traffic management features can also help in performing different deployment strategies such as canary rollouts and A/B testing.

The traffic management model relies on the Envoy proxy (sidecar) deployed as an additional container in your application’s pod. All traffic sent and receive by an application is proxied through the Envoy sidecar, which makes it easy to control traffic in the mesh without changing your application.

Security

Microservice architectures may have particular security needs such as traffic encryption to prevent man-in-the-middle attacks, use mutual TLS and fine-grained access policies to provide flexible acces control, and auditing to determine who did what and when.

The Istio security features provide strong identity, powerful policy, transparent TLS encryption, authn/authz and audit tools to protect your services and data, including:

  • Security by default: no changes to application/infrastructure,
  • Defense in depth: integrate with existing security systems, and
  • Zero-trust network: build security on distrusted networks.

Observability

Istio generates detailed information for all communication across the mesh. This provides observability of service behavior, allowing for better troubleshooting, maintainance and optimization of applications. It also allows a thorough understanding of how applications are interacting with one another and Istio components.

Types of telemetry used:

  • Metrics: based on latency, traffic, errors and saturation,
  • Distributed Traces: providing a detailed understanding of the call flows and service dependencies, and
  • Access Logs: full record of each request, including source and destination metadata.

Extensibility

Istio allows for extensions to provide custom functionality. WebAssembly is a sandbox technology which can be used to extend the Istio proxy (Envoy).

Summary

With the rise of microservices and complexity to manage them, Istio layers transparently onto such distributed microservice architectures, providing a uniform way to connect, secure and monitor your application.

Istio is playing a key role for ProTego, using features like traffic management, enforcing security with mTLS and security policies, and providing service level detailed metrics.

References

This blog post was written for the ProTego project by Noel Tomas (ICE).