Unlocking EnvoyFilter: Namespace Isolation & Advanced Traffic Control in Istio

Istio Traffic Management Strategy

Istio’s traffic management is centrally controlled by Pilot, which distributes configuration to Envoy via the ADS (Aggregated Discovery Service) interface in the order CDS, EDS, LDS, RDS. Pilot is stateless; all resources are stored as CRDs in the Kubernetes cluster and pushed to Envoy when events occur.

While unified configuration simplifies operations, it limits customization. To fine‑tune sidecar traffic management, the EnvoyFilter resource is introduced.

Envoy Architecture

EnvoyFilter is a custom Istio resource that updates Envoy’s filter chain, providing powerful extensibility. Envoy contains two types of filters: L4 (network) and L7 (HTTP) filters, each executed in a defined order.

listener:
  filter_chains:
  - filters:
    - name: {L4-filter-name}
    - name: envoy.http_connection_manager
      config:
        http_filters:
        - name: {L7-filter-name}

L4 filters include HTTP connection manager, MySQL proxy, rate limit, RBAC, Redis proxy, TCP proxy, etc. L7 filters (under the HTTP connection manager) include CORS, external authorization, fault injection, health check, JWT authentication, Lua, router, and more.

EnvoyFilter Case Study

Requirement: Return HTTP 444 for requests whose header contains foo:bar. This is achieved by inserting the envoy.fault filter at the first position of the inbound listener’s filter chain.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: simple-envoy-filter
spec:
  workloadLabels:
    app: helloworld
  filters:
  - listenerMatch:
      listenerType: SIDECAR_INBOUND
      listenerProtocol: HTTP
    insertPosition:
      index: FIRST
    filterType: HTTP
    filterName: envoy.fault
    filterConfig:
      abort:
        percentage:
          numerator: 100
          denominator: HUNDRED
        httpStatus: 444
      headers:
        name: foo
        exactMatch: bar

The resulting XDS listener configuration shows the envoy.fault filter inserted as the first HTTP filter, confirming the expected behavior.

dynamic_active_listeners:
- listener:
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          http_filters:
          - name: envoy.fault
            config:
              abort:
                percentage:
                  denominator: HUNDRED
                  numerator: 100
                httpStatus: 444
              headers:
                name: bar
                exactMatch: foo
          - name: istio_authn
          - name: mixer

Root Cause Analysis: Lack of Isolation

Inspecting Pilot (v1.1.2) source reveals that InsertUserFilter merges EnvoyFilters across the entire cluster, ignoring namespace boundaries. Consequently, filters from one namespace can affect workloads in another, leading to unexpected response codes.

Solution: Namespace‑Level Isolation

The KUN team modified Istio to enforce namespace‑scoped EnvoyFilter application, ensuring that custom filters affect only workloads within the same namespace.

With this isolation, KUN now safely supports 175 applications on Istio, and users can create EnvoyFilters in their own namespaces without interfering with others.

Continuous Improvement: Validation

Invalid filter configurations can crash Envoy. To prevent this, the team enhanced istio‑galley validation, checking that filters referenced in an EnvoyFilter are either natively supported by Envoy or compiled into istio‑proxy.

#kubectl -n foo create -f
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: network-filter
spec:
  workloadLabels:
    version: v1
  filters:
  - listenerMatch:
      listenerType: SIDECAR_INBOUND
      listenerProtocol: HTTP
    insertPosition:
      index: LAST
    filterType: NETWORK
    filterName: envoy.filters.unknown
    filterConfig:
      key: value

The admission webhook now rejects such configurations with clear error messages, e.g.:

Error from server: error when creating "networkfilter.yaml": admission webhook "pilot.validation.istio.io" denied the request: configuration is invalid: envoy filter: unknown

Conclusion

Service Mesh abstracts infrastructure, letting developers focus on business logic. The KUN team’s early adoption of Istio, combined with enhancements like IPv6 support, resource isolation, and robust validation, demonstrates the practical benefits of cloud‑native service mesh technologies and contributes back to the open‑source community.