Application Layer Protection for Istio Service Mesh

by Alfred Chung on December 3, 2019

Today, Signal Sciences announced another industry-first: the launch of our next-gen WAF integration with Istio service mesh. As development teams move from monolithic to distributed, microservices-based application architectures, managing the security and traceability of the network connections between services in a cloud-native application has become an increasingly complex task.

A single north-south (client to app) web request coming into your cluster can proliferate into dozens or even hundreds of east-west (service to service) web requests within a Kubernetes cluster! When this occurs, various security scenarios arise:

How can you ensure that the traffic running between services is legitimate?
Or that you have good traceability and the ability to see which microservices handled a particular incoming north/south request?
If a microservice were to become compromised, could you detect and block attacks originating from that microservice and directed at other containers in your Kubernetes cluster?

Fortunately, service mesh technologies, like Istio, are seeing rapidly growing adoption as a solution to some of these problems, but it turns out, not quite all of them. Signal Sciences’ cloud-native WAF completes the service mesh security picture by integrating directly with Istio to provide layer 7 visibility and protection to both north-south and east-west traffic in your Kubernetes cluster.

What is a Service Mesh?

Much has been written about service meshes (see Matt Klein’s excellent blog post) but if the technology is new to you, here’s a basic primer: a service mesh is composed of two parts, a “data plane,” typically Envoy or a similar proxy, and a “control plane,” like Istio (or other competing projects like Linkerd, Hashicorp’s Consul, AWS App Mesh). The data plane is formed by multiple instances of a proxy each attached to a microservice workload and the control plane centralizes the configuration of those proxies to create a distributed system. With a service mesh, some of the things you can do are:

Load balance between multiple instances of a microservice
Set security policies to govern which microservices can talk to which other microservices
Trace and log the communications between microservices
Set fine grain routing rules, (e.g., send 90% of traffic to service instance one, 10% to service instance two for canary testing)
Inject faults (chaos testing) to see how your app recovers
Manage the authentication and authorization of service-to-service communications

A service mesh can provide critical security features to your microservices architecture app. However, the technology focuses on layer 3/ layer 4 network security — but there’s nothing in a service mesh that can detect or block layer 7 attacks, such as SQL injection or cross-site scripting. With the Signal Sciences integration with Istio, this security gap is addressed.

Sponsorships Available

It’s Coming from Inside the House!

Web Application Firewalls have traditionally been deployed at the edge, used to block web attacks coming from external clients. But with the move to the cloud and microservices architecture, application security must evolve to ensure that not only external malicious requests are detected and blocked, but also malicious requests that propagate or even originate from within the Kubernetes cluster.

Edge-based WAFs have a number of benefits, such as ease-of-deployment and scalability, but they are completely blind to malicious east-west, or service-to-service requests. Signal Sciences cloud-native WAF can be deployed at the edge, or within an application cluster using a language-based module, or by plugging into a web server or proxy such as NGINX, HAProxy, and Envoy. With the integration with Istio service mesh and its centralized management of the distributed Envoy data plane, the Signal Sciences agent can easily plug into the proxies deployed on microservices and protect malicious traffic coming from outside the application cluster or within.

Divide and Conquer

The feature richness of Istio service mesh enables developers to focus on what’s important to them: implementing the business logic of an application. With Istio handling concerns like service-to-service authentication and authorization, development teams can offload a significant portion of securing their application to the DevOps team, who, among many other things, manages the configuration of the infrastructure the application runs on, of which Istio is a part of. It’s a win-win: developers can move fast on the application logic while DevOps ensures every deploy is secure.

Signal Sciences cloud-native WAF already offers a number of DevOps-friendly deployment options, whether that is being configured as a reverse proxy, deployed as an NGINX or other web server module, or in an API gateway such as Kong. Now that the Signal Sciences agent can integrate with Istio, DevOps teams have an easy way to instrument their microservices architecture applications with an award winning next-gen WAF to protect against layer 7 web attacks coming into the application cluster (north-south) and within (east-west).

How Signal Sciences Works with Istio

Since Istio uses the Envoy proxy as its data plane, the Signal Sciences agent leverages the same ext_authz filter to inspect incoming web requests as when connecting the agent to standalone Envoy directly.

Starting in version 1.3, Istio has an enhanced EnvoyFilter API that allows better control of the Envoy proxy configuration for the Signal Sciences agent, allowing it to inspect traffic routed through the Istio data plane via the same method as a direct integration to Envoy. The Signal Sciences agent would then be deployed as a sidecar in the microservice’s Kubernetes pod.

So, integrating Signal Sciences with an Istio service mesh is a two-step process:

Add the Signal Sciences agent as a docker sidecar to your microservices, configured as a gRPC listener
Add an Istio EnvoyFilter object in the Istio configuration YAML

No code changes or additional dependencies are required in the microservice or application. For more detailed instructions, please refer to the documentation.

To learn more about how Signal Sciences next-gen WAF protects both traditional and cloud-native web applications, request a demo here!

The post Application Layer Protection for Istio Service Mesh appeared first on Signal Sciences.