Edge Security Policy at Kubernetes Ingress Using Helm and Envoy

Introduction: EnRoute Helm Chart

Helm is a popular package manager choice for Kubernetes. Installation of software, managing versions, upgrading versions, and finding charts from the registry are key benefits of Helm.

EnRoute helm chart installs the EnRoute Ingress Controller and provides easy configuration options to define policy for a service. The helm chart provides fine-grained control to define L7 policies with its ability to enable/disable plugins for a service using configuration options that can be specified when the helm is invoked.

Is Service Mesh Right for Your Infrastructure?

Intro: About Microservices

The introduction of cloud-native applications and containers changed the way of how people structure and provision applications. Deploying and configuring physical servers at every edge location and trying to balance the load is just not feasible for dynamic loads and hybrid infrastructures.  The solution to this problem is microservices.

In addition to supporting dynamic scalability, the move from monolithic applications to microservices avoids the bottlenecks of a central database and supports portability and code reuse. It also provides additional benefits of easier automation, integration in CI/CD pipeline, observability, and high availability, although microservices security and management may create certain new challenges.

Service Mesh and Cloud-Native Microservices

We all want this kind of service.


You may also like: Istio Service Mesh, the Step-by-Step Guide, Part 1: Theory

Microservices need to be decoupled, flexible, operationally transparent, data-aware and elastic. Most material from last year only discusses point-to-point architectures with tightly coupled and non-scalable technologies like REST / HTTP. This blog post takes a look at cutting edge technologies like Apache Kafka, Kubernetes, Envoy, Linkerd and Istio to implement a cloud-native service mesh to solve these challenges and bring microservices to the next level of scale, speed, and efficiency.

Guidance for Building a Control Plane for Envoy

Identify Which Components You Need for Your Control Plane

As the spectrum of operating environments varies wildly, so too could the components needed to implement a control plane for Envoy. For example, at one extreme, if you have Envoy files statically generated at build time and shipped to your Envoy, you will need components like:

  • Template engine
  • Data store/VCS
  • Per-service configurations
  • An orchestrator to put the pieces together
  • A way to deliver these to Envoy and hot restart

On the other hand, if you opt to use the gRPC streaming xDS implementation, you'll need: