Web Application Security

Signal Sciences Broadens Integrations with Envoy Proxy Support

Brendon Macaraeg

Brendon Macaraeg is Director of Product Marketing at Signal Sciences. Previously with CrowdStrike and Symantec, he focused on evangelizing and marketing security offerings. Outside of work, Brendon keeps busy with his wife and kids enjoying outdoor activities.


Today we’re excited to announce that we’ve broadened our integrations by supporting Envoy in limited availability. This further validates our ability to protect our customers apps, APIs and microservices, wherever they run them.

Envoy as a Front Proxy

Envoy is most popular as part of the open source project launched by Google, Lyft and IBM called Istio. The project now includes Pivotal, NGINX, among others in the industry.  Envoy is a high performance open source proxy with the goal of making the network transparent to applications.

This blog covers how Envoy acts as a service mesh and, as a key piece of Signal Sciences integration, functions as a Front Proxy. When acting as a Front Proxy, Envoy load balances public north-south traffic from the Internet—that’s HTTP traffic that needs to be protected against layer seven attacks.

If you’re familiar with Signal Sciences architecture, you’re aware we have a patented module-agent software pair. The module forwards requests to the agent, which performs detection and decisioning on the web requests it inspects. The benefit of this split approach is that Signal Sciences is fail-open, which is important to gain credibility as a security service with DevOps and operations teams.

Our engineering team worked with the Envoy maintainers to build Signal Sciences into the Envoy project so that Envoy acts as the “module” forwarding requests to our agent.

 Signal Sciences Envoy Architecture 

Securing Web Services Running Behind Envoy

By deploying Signal Sciences on Envoy at the edge, all services running behind Envoy are protected. Unlike a traditional WAF that would have to define rulesets for each service, application or API behind the WAF, Signal Sciences SmartParse technology detects malicious payloads dynamically without any rule matching. For further context, you can read our Detection and Blocking white paper on how we do this so that 95% of our customers trust us to run in blocking mode. Our architecture provides scalability that is orders of magnitude greater than individually tuning rulesets for “n” number of services and applications deployed behind the proxy.

Service Mesh Defined

Envoy service mesh has gained significant industry traction since 2014 and we’re seeing many tout their own service meshes: NGINX, Kong, Envoy, HA Proxy, Linkerd.  Benefits of Envoy service mesh include a lightweight footprint, powerful routing constructs, and flexible observability support.

Service mesh as a concept can be described in simple terms as a system of connected sidecar containers that function as proxies to the services they’re running beside. This is preferred to running a single proxy in front of all containers because it simplifies three core areas: networking, security, and observation. Being configurable, service mesh provides a low‑latency infrastructure layer designed to handle a high volume of network‑based interprocess communication between application infrastructure services using APIs.

Service Mesh Advantages

From a development operations point of view, there are three key advantages to leveraging service mesh:

  1. Networking: a service mesh abstracts network dependencies from application code and pushes it down to the infrastructure layer.
  2. Security: the sidecar proxies handle encryption between all services. This is important because your services are communicating over the network when they used to do so inside a monolith.
  3. Observation: the granularity of seeing individual services through the sidecar proxies helps teams determine where problems are in any given service. Before with a single proxy, you didn’t have that visibility into which particular service was causing the issue.

Istio as Traffic Controller and Security Enforcer

We can’t talk about service mesh without talking about Istio. If service mesh is the network of sidecar proxy containers, Istio is the controller that decides how to route traffic to each individual proxy-service pair. It also enforces security by issuing (and rotating) certificates and keys to the services that they use to encrypt traffic.  It’s written in Go, and as part of the open source project, pairs with Envoy out of the gate, but is platform agnostic at heart. 

The best explanation of service mesh data and control planes perhaps comes from Matt Klein on the team at Lyft who built Envoy.

The control plane takes a set of isolated stateless sidecar proxies and turns them into a distributed system.”

You can learn more from Matt in this presentation about Envoy’s origins, its high level architecture overview, and future directions.

We’re excited to see how service mesh adoption continues with our customers and the market at large and, specifically, how we can enhance application security in this new construct.

 If you’d like to learn more about how Signal Sciences can enhance the security of your apps, microservices and APIs, request a demo!

Photo by Zara Walker on Unsplash