Zero Trust Application Networking with Envoy Proxy

Betty Junod | October 12, 2020

Security is an evergreen requirement for any system, and in recent years, the concept of Zero Trust has gained in popularity as a different security model to protect organizations and their IT portfolio from the increasing business risk of security incidents. Traditional security practices and tools are designed to secure the perimeter and by default assume the things inside the firewall are trusted. In the days of static applications with identity assigned via network boundary, and  access from corporate issued devices on a LAN, this made sense.The advent of public cloud, proliferation of devices, and distributed and ephemeral workloads challenge the previous security model.

Why? It’s because today’s IT stack bends and in many cases, breaks the traditional perimeter.

The Call is Coming from Inside the House

Zero Trust assumes that by default, nothing inside AND outside the corporate firewall should be trusted and that everyone and everything (systems and people) must be identified, verified, and specifically granted the minimum amount of permission needed to complete its function. While this may initially sound like a hostile view of the world to some, the dynamic and heterogeneous nature of modern systems require this change in perspective to proactively protect the environment from attacks, human error, or misbehaving systems. 

When we think about how access to infrastructure and applications has changed, we understand that a malicious actor trying to break into the firewall is just one of the concerns. The hacker is still trying to break into the corporate network but that network is now in the data center, public cloud, or SaaS application holding customer data, and APIs connect the traffic between these assets. Human error or a system stuck in a race condition can compromise not only that system, but the other systems dependent on it and those that share the network with it. 

BEFORETODAY
  • Do not trust anything outside the firewall
  • Secure the perimeter
  • Provide a single point of entry 
  • Trust anything inside corporate firewall or specific zones
  • Do not trust anything outside the firewall
  • Secure the perimeter
  • Multiple points of entry and exit 
  • Do not trust anything inside the corporate firewall

Zero trust does not eliminate the need to secure the perimeter, it merely flips how we think about security to go beyond traditional perimeters and adjusts to your business needs and compliance requirements. 

Zero Trust for Microservices

While zero trust covers a broad surface area for comprehensive security, you can apply those principles specifically to microservices architecture. As a decentralized and loosely coupled set of services, the network between the services is critical to a properly functioning application. This can expand the surface area for risk if not approached with zero-trust principles. 

In microservices, there are three primary traffic patterns including ingress, intra-cluster, and egress. Ingress (north/south) is traffic that comes from external sources to access backend application services. Intra-cluster is the service to service communication (east/west) that happens between services within a boundary. Egress is the traffic that exits the cluster to reach an external service or go between boundaries.

Across these traffic patterns, you can consider the following to start applying zero trust principles:

  • Maintain perimeter protection 
  • Identify people and systems inside and outside your organization that need to access
  • Define the authentication and authorization workflows needed to grant access with the ability to scope the amount of access.
  • Segmentation of application networks within clusters to restrict access and also limit the blast radius in case of a breach event.
  • Encryption of application traffic and defining which traffic patterns require this method
  • Observe and Monitor the traffic patterns for any anomalies 

Things like service/end-user identity, authentication, authorization, encryption, and monitoring can be applied to all three traffic patterns while segmentation is largely within the domain of the application and filtering happens at Ingress. 

How can these be implemented? 

Envoy Proxy to the Rescue

Envoy is a highly performant and extensible proxy designed for distributed environments that is at the heart of modern edge gateway and service-mesh technology. Through a series of built-in filters, custom filters, integrations to external systems, and control-plane interactions, an Envoy powered data plane can be at the core of enabling zero-trust networking for your applications.

Gloo, our API gateway and Service Mesh Hub are products built on Envoy as control planes for the edge/ingress and service mesh data planes within a single and across multiple clusters. Gloo enables teams to implement zero trust principles for traffic entering and exiting the application environment while Service Mesh Hub enables consistent configuration and policy of service-mesh clusters. 

Now let’s review that list again with capabilities offered by Gloo and Service Mesh Hub with Envoy Proxy at the edge and within the cluster.

  • Maintain perimeter protection and reinforce it with a Web Application Firewall built into the gateway
  • Identity, AuthN/AuthZ, and Rate Limits guarantee requestors are verified before routed to the service with limits on how much the service can be accessed within a specified time. Gloo integrates with Auth systems like OIDC, LDAP, API Keys and JWT, the Developer Portal provides secure access to APIs for developers inside and outside the organization and rate limits can be applied to protect services from being overrun. 
  • Encrypt application traffic with optional TLS/mTLS for the ingress traffic at the gateway and service to service traffic in the service mesh.
  • Metrics and logs from the proxies can be visualized in Prometheus, Grafana, or a dashboard of your choice to monitor behavior or integrate to monitoring systems and set alerts. 

Conclusion

When it comes to microservices and service mesh, there are many different deployment patterns depending on your application requirements and ways to implement the different security functionality to maintain agility and speed without risk. Additionally, the extensibility of Solo.io’s Gloo and Service Mesh Hub mean that it can work with the systems you have today and integrates to cloud-native security and monitoring tools for a comprehensive environment. Visit our website and check out the links below to learn more:

Back to Blog