Envoy Filter

 18 minute read  

EnvoyFilter provides a mechanism to customize the Envoy configuration generated by istiod. Use EnvoyFilter to modify values for certain fields, add specific filters, or even add entirely new listeners, clusters, etc. This feature must be used with care, as incorrect configurations could potentially destabilize the entire mesh. Unlike other Istio networking objects, EnvoyFilters are additively applied. Any number of EnvoyFilters can exist for a given workload in a specific namespace. The order of application of these EnvoyFilters is as follows: all EnvoyFilters in the config root namespace, followed by all matching EnvoyFilters in the workload’s namespace.

NOTE 1: Some aspects of this API are deeply tied to the internal implementation in Istio networking subsystem as well as Envoy’s XDS API. While the EnvoyFilter API by itself will maintain backward compatibility, any envoy configuration provided through this mechanism should be carefully monitored across Istio proxy version upgrades, to ensure that deprecated fields are removed and replaced appropriately.

NOTE 2: When multiple EnvoyFilters are bound to the same workload in a given namespace, all patches will be processed sequentially in order of creation time. The behavior is undefined if multiple EnvoyFilter configurations conflict with each other.

NOTE 3: To apply an EnvoyFilter resource to all workloads (sidecars and gateways) in the system, define the resource in the config root namespace, without a workloadSelector.

The example below declares a global default EnvoyFilter resource in the root namespace called istio-config, that adds a custom protocol filter on all sidecars in the system, for outbound port 9307. The filter should be added before the terminating tcp_proxy filter to take effect. In addition, it sets a 30s idle timeout for all HTTP connections in both gateways and sidecars.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-protocol
  namespace: istio-config # as defined in meshConfig resource.
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: SIDECAR_OUTBOUND # will match outbound listeners in all sidecars
      listener:
        portNumber: 9307
        filterChain:
          filter:
            name: "envoy.filters.network.tcp_proxy"
    patch:
      operation: INSERT_BEFORE
      value:
        # This is the full filter config including the name and typed_config section.
        name: "envoy.extensions.filters.network.mongo_proxy"
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.mongo_proxy.v3.MongoProxy"
          ...
  - applyTo: NETWORK_FILTER # http connection manager is a filter in Envoy
    match:
      # context omitted so that this applies to both sidecars and gateways
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        name: "envoy.filters.network.http_connection_manager"
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
          common_http_protocol_options:
            idle_timeout: 30s

The following example enables Envoy’s Lua filter for all inbound HTTP calls arriving at service port 8080 of the reviews service pod with labels “app: reviews”, in the bookinfo namespace. The lua filter calls out to an external service internal.org.net:8888 that requires a special cluster definition in envoy. The cluster is also added to the sidecar as part of this configuration.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: reviews-lua
  namespace: bookinfo
spec:
  workloadSelector:
    labels:
      app: reviews
  configPatches:
    # The first patch adds the lua filter to the listener/http connection manager
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        portNumber: 8080
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value: # lua filter specification
       name: envoy.filters.http.lua
       typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
          defaultSourceCode:
            inlineString: |
              function envoy_on_request(request_handle)
                -- Make an HTTP call to an upstream host with the following headers, body, and timeout.
                local headers, body = request_handle:httpCall(
                 "lua_cluster",
                 {
                  [":method"] = "POST",
                  [":path"] = "/acl",
                  [":authority"] = "internal.org.net"
                 },
                "authorize call",
                5000)
              end
  # The second patch adds the cluster that is referenced by the lua code
  # cds match is omitted as a new cluster is being added
  - applyTo: CLUSTER
    match:
      context: SIDECAR_OUTBOUND
    patch:
      operation: ADD
      value: # cluster specification
        name: "lua_cluster"
        type: STRICT_DNS
        connect_timeout: 0.5s
        lb_policy: ROUND_ROBIN
        load_assignment:
          cluster_name: lua_cluster
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    protocol: TCP
                    address: "internal.org.net"
                    port_value: 8888

The following example overwrites certain fields (HTTP idle timeout and X-Forward-For trusted hops) in the HTTP connection manager in a listener on the ingress gateway in istio-system namespace for the SNI host app.example.com:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: hcm-tweaks
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER # http connection manager is a filter in Envoy
    match:
      context: GATEWAY
      listener:
        filterChain:
          sni: app.example.com
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
          xff_num_trusted_hops: 5
          common_http_protocol_options:
            idle_timeout: 30s

The following example inserts an attributegen filter that produces istio_operationId attribute which is consumed by the istio.stats filter. filterClass: STATS encodes this dependency.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: reviews-request-operation
  namespace: myns
spec:
  workloadSelector:
    labels:
      app: reviews
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: ADD
      filterClass: STATS # This filter will run *before* the Istio stats filter.
      value:
        name: istio.request_operation
        typed_config:
         "@type": type.googleapis.com/udpa.type.v1.TypedStruct
         type_url: type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
         value:
           config:
             configuration: |
               {
                 "attributes": [
                   {
                     "output_attribute": "istio_operationId",
                     "match": [
                       {
                         "value": "ListReviews",
                         "condition": "request.url_path == '/reviews' && request.method == 'GET'"
                       }]
                   }]
               }
             vm_config:
               runtime: envoy.wasm.runtime.null
               code:
                 local: { inline_string: "envoy.wasm.attributegen" }

The following example inserts an http ext_authz filter in the myns namespace.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: myns-ext-authz
  namespace: myns
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: ADD
      filterClass: AUTHZ # This filter will run *after* the Istio authz filter.
      value:
        name: envoy.filters.http.ext_authz
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
          grpc_service:
            envoy_grpc:
              cluster_name: acme-ext-authz
            initial_metadata:
            - key: foo
              value: myauth.acme # required by local ext auth server.

A workload in the myns namespace needs to access a different ext_auth server that does not accept initial metadata. Since proto merge cannot remove fields, the following configuration uses the REPLACE operation. If you do not need to inherit fields, REPLACE is preferred over MERGE.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: mysvc-ext-authz
  namespace: myns
spec:
  workloadSelector:
    labels:
      app: mysvc
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: REPLACE
      value:
        name: envoy.filters.http.ext_authz
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
          grpc_service:
            envoy_grpc:
              cluster_name: acme-ext-authz-alt

The following example deploys a Wasm extension for all inbound sidecar HTTP requests.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: wasm-example
  namespace: myns
spec:
  configPatches:
  # The first patch defines a named Wasm extension and provides a URL to fetch Wasm binary from,
  # and the binary configuration. It should come before the next patch that applies it.
  # This resource is visible to all proxies in the namespace "myns". It is possible to provide
  # multiple definitions for the same name "my-wasm-extension" in multiple namespaces. We recommend that:
  # - if overriding is desired, then the root level definition can be overridden per namespace with REPLACE.
  # - if overriding is not desired, then the name should be qualified with the namespace "myns/my-wasm-extension",
  #   to avoid accidental name collisions.
  - applyTo: EXTENSION_CONFIG
    patch:
      operation: ADD
      value:
        name: my-wasm-extension
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
          config:
            root_id: my-wasm-root-id
            vm_config:
              vm_id: my-wasm-vm-id
              runtime: envoy.wasm.runtime.v8
              code:
                remote:
                  http_uri:
                    uri: http://my-wasm-binary-uri
            configuration:
              "@type": "type.googleapis.com/google.protobuf.StringValue"
              value: |
                {}
  # The second patch instructs to apply the above Wasm filter to the listener/http connection manager.
  - applyTo: HTTP_FILTER
    match:
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: my-wasm-extension # This must match the name above
        config_discovery:
          config_source:
            ads: {}
          type_urls: ["type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm"]

The following example inserts an envoy.filters.listener.proxy_protocol listener filter before the envoy.filters.listener.tls_inspector.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: listener-filter-example
  namespace: myns
spec:
  configPatches:
  - applyTo: LISTENER_FILTER
    match:
      context: SIDECAR_INBOUND # will match inbound listeners in all sidecars
      listener:
        portNumber: 15006
        listenerFilter: "envoy.filters.listener.tls_inspector"
    patch:
      operation: INSERT_BEFORE
      value:
        # This is the full filter config including the name and typed_config section.
        name: "envoy.filters.listener.proxy_protocol"
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.listener.proxy_protocol.v3.ProxyProtocol"

EnvoyFilter

EnvoyFilter provides a mechanism to customize the Envoy configuration generated by istiod.

FieldDescription
workloadSelector
WorkloadSelector

Criteria used to select the specific set of pods/VMs on which this patch configuration should be applied. If omitted, the set of patches in this configuration will be applied to all workload instances in the same namespace. If the EnvoyFilter is present in the config root namespace, it will be applied to all applicable workloads in any namespace.

targetRefs
PolicyTargetReference[]

The targetRefs specifies a list of resources the policy should be applied to. The targeted resources specified will determine which workloads the policy applies to.

Currently, the following resource attachment types are supported:

  • kind: Gateway with group: gateway.networking.k8s.io in the same namespace.
  • kind: Service with "" in the same namespace. This type is only supported for waypoints.

If not set, the policy is applied as defined by the selector. At most one of the selector and targetRefs can be set.

NOTE: If you are using the targetRefs field in a multi-revision environment with Istio versions prior to 1.22, it is highly recommended that you pin the policy to a revision running 1.22+ via the istio.io/rev label. This is to prevent proxies connected to older control planes (that don’t know about the targetRefs field) from misinterpreting the policy as namespace-wide during the upgrade process.

NOTE: Waypoint proxies are required to use this field for policies to apply; selector policies will be ignored.

configPatches
EnvoyConfigObjectPatch[]

One or more patches with match conditions.

priority
int32

Priority defines the order in which patch sets are applied within a context. When one patch depends on another patch, the order of patch application is significant. The API provides two primary ways to order patches. Patch sets in the root namespace are applied before the patch sets in the workload namespace. Patches within a patch set are processed in the order that they appear in the configPatches list.

The default value for priority is 0 and the range is [ min-int32, max-int32 ]. A patch set with a negative priority is processed before the default. A patch set with a positive priority is processed after the default.

It is recommended to start with priority values that are multiples of 10 to leave room for further insertion.

Patch sets are sorted in the following ascending key order: priority, creation time, fully qualified resource name.

ProxyMatch

One or more properties of the proxy to match on.

FieldDescription
proxyVersion
string

A regular expression in golang regex format (RE2) that can be used to select proxies using a specific version of istio proxy. The Istio version for a given proxy is obtained from the node metadata field ISTIO_VERSION supplied by the proxy when connecting to istiod. This value is embedded as an environment variable (ISTIO_META_ISTIO_VERSION) in the Istio proxy docker image. Custom proxy implementations should provide this metadata variable to take advantage of the Istio version check option.

metadata
map<string, string>

Match on the node metadata supplied by a proxy when connecting to istiod. Note that while Envoy’s node metadata is of type Struct, only string key-value pairs are processed by istiod. All keys specified in the metadata must match with exact values. The match will fail if any of the specified keys are absent or the values fail to match.

ClusterMatch

Conditions specified in ClusterMatch must be met for the patch to be applied to a cluster.

FieldDescription
portNumber
uint32

The service port for which this cluster was generated. If omitted, applies to clusters for any port. Note: for inbound cluster, it is the service target port.

service
string

The fully qualified service name for this cluster. If omitted, applies to clusters for any service. For services defined through service entries, the service name is same as the hosts defined in the service entry. Note: for inbound cluster, this is ignored.

subset
string

The subset associated with the service. If omitted, applies to clusters for any subset of a service.

name
string

The exact name of the cluster to match. To match a specific cluster by name, such as the internally generated Passthrough cluster, leave all fields in clusterMatch empty, except the name.

RouteConfigurationMatch

Conditions specified in RouteConfigurationMatch must be met for the patch to be applied to a route configuration object or a specific virtual host within the route configuration.

FieldDescription
portNumber
uint32

The service port number or gateway server port number for which this route configuration was generated. If omitted, applies to route configurations for all ports.

portName
string

Applicable only for GATEWAY context. The gateway server port name for which this route configuration was generated.

gateway
string

The Istio gateway config’s namespace/name for which this route configuration was generated. Applies only if the context is GATEWAY. Should be in the namespace/name format. Use this field in conjunction with the portNumber and portName to accurately select the Envoy route configuration for a specific HTTPS server within a gateway config object.

vhost
VirtualHostMatch

Match a specific virtual host in a route configuration and apply the patch to the virtual host.

name
string

Route configuration name to match on. Can be used to match a specific route configuration by name, such as the internally generated http_proxy route configuration for all sidecars.

RouteMatch

Match a specific route inside a virtual host in a route configuration.

FieldDescription
name
string

The Route objects generated by default are named as default. Route objects generated using a virtual service will carry the name used in the virtual service’s HTTP routes.

action
Action

Match a route with specific action type.

Action

Action refers to the route action taken by Envoy when a http route matches.

NameDescription
ANY

All three route actions

ROUTE

Route traffic to a cluster / weighted clusters.

REDIRECT

Redirect request.

DIRECT_RESPONSE

directly respond to a request with specific payload.

VirtualHostMatch

Match a specific virtual host inside a route configuration.

FieldDescription
name
string

The VirtualHosts objects generated by Istio are named as host:port, where the host typically corresponds to the VirtualService’s host field or the hostname of a service in the registry.

route
RouteMatch

Match a specific route within the virtual host.

ListenerMatch

Conditions specified in a listener match must be met for the patch to be applied to a specific listener across all filter chains, or a specific filter chain inside the listener.

FieldDescription
portNumber
uint32

The service port/gateway port to which traffic is being sent/received. If not specified, matches all listeners. Even though inbound listeners are generated for the instance/pod ports, only service ports should be used to match listeners.

filterChain
FilterChainMatch

Match a specific filter chain in a listener. If specified, the patch will be applied to the filter chain (and a specific filter if specified) and not to other filter chains in the listener.

listenerFilter
string

Match a specific listener filter. If specified, the patch will be applied to the listener filter.

name
string

Match a specific listener by its name. The listeners generated by istiod are typically named as IP:Port.

FilterChainMatch

For listeners with multiple filter chains (e.g., inbound listeners on sidecars with permissive mTLS, gateway listeners with multiple SNI matches), the filter chain match can be used to select a specific filter chain to patch.

FieldDescription
name
string

The name assigned to the filter chain.

sni
string

The SNI value used by a filter chain’s match condition. This condition will evaluate to false if the filter chain has no sni match.

transportProtocol
string

Applies only to SIDECAR_INBOUND context. If non-empty, a transport protocol to consider when determining a filter chain match. This value will be compared against the transport protocol of a new connection, when it’s detected by the tls_inspector listener filter.

Accepted values include:

  • raw_buffer - default, used when no transport protocol is detected.
  • tls - set when TLS protocol is detected by the TLS inspector.
applicationProtocols
string

Applies only to sidecars. If non-empty, a comma separated set of application protocols to consider when determining a filter chain match. This value will be compared against the application protocols of a new connection, when it’s detected by one of the listener filters such as the http_inspector.

Accepted values include: h2, http/1.1, http/1.0

filter
FilterMatch

The name of a specific filter to apply the patch to. Set this to envoy.filters.network.http_connection_manager to add a filter or apply a patch to the HTTP connection manager.

destinationPort
uint32

The destination_port value used by a filter chain’s match condition. This condition will evaluate to false if the filter chain has no destination_port match.

FilterMatch

Conditions to match a specific filter within a filter chain.

FieldDescription
name
string

The filter name to match on. For standard Envoy filters, canonical filter names should be used.

subFilter
SubFilterMatch

The next level filter within this filter to match upon. Typically used for HTTP Connection Manager filters and Thrift filters.

SubFilterMatch

Conditions to match a specific filter within another filter. This field is typically useful to match a HTTP filter inside the envoy.filters.network.http_connection_manager network filter. This could also be applicable for thrift filters.

FieldDescription
name
string

The filter name to match on.

Patch

Patch specifies how the selected object should be modified.

FieldDescription
operation
Operation

Determines how the patch should be applied.

value
Struct

The JSON config of the object being patched. This will be merged using proto merge semantics with the existing proto in the path.

filterClass
FilterClass

Determines the filter insertion order.

Operation

Operation denotes how the patch should be applied to the selected configuration.

NameDescription
INVALID
MERGE

Merge the provided config with the generated config using proto merge semantics. If you are specifying config in its entirety, use REPLACE instead.

ADD

Add the provided config to an existing list (of listeners, clusters, virtual hosts, network filters, or http filters). This operation will be ignored when applyTo is set to ROUTE_CONFIGURATION, or HTTP_ROUTE.

REMOVE

Remove the selected object from the list (of listeners, clusters, virtual hosts, network filters, routes, or http filters). Does not require a value to be specified. This operation will be ignored when applyTo is set to ROUTE_CONFIGURATION, or HTTP_ROUTE.

INSERT_BEFORE

Insert operation on an array of named objects. This operation is typically useful only in the context of filters or routes, where the order of elements matter. Routes should be ordered based on most to least specific matching criteria since the first matching element is selected. For clusters and virtual hosts, order of the element in the array does not matter. Insert before the selected filter or sub filter. If no filter is selected, the specified filter will be inserted at the front of the list.

INSERT_AFTER

Insert operation on an array of named objects. This operation is typically useful only in the context of filters or routes, where the order of elements matter. Routes should be ordered based on most to least specific matching criteria since the first matching element is selected. For clusters and virtual hosts, order of the element in the array does not matter. Insert after the selected filter or sub filter. If no filter is selected, the specified filter will be inserted at the end of the list.

INSERT_FIRST

Insert operation on an array of named objects. This operation is typically useful only in the context of filters or routes, where the order of elements matter. Routes should be ordered based on most to least specific matching criteria since the first matching element is selected. For clusters and virtual hosts, order of the element in the array does not matter. Insert first in the list based on the presence of selected filter or not. This is specifically useful when you want your filter first in the list based on a match condition specified in Match clause.

REPLACE

Replace contents of a named filter with new contents. REPLACE operation is only valid for HTTP_FILTER and NETWORK_FILTER. If the named filter is not found, this operation has no effect.

FilterClass

FilterClass determines the filter insertion point in the filter chain relative to the filters implicitly inserted by the control plane. It is used in conjunction with the ADD operation. This is the preferred insertion mechanism for adding filters over the INSERT_* operations since those operations rely on potentially unstable filter names. Filter ordering is important if your filter depends on or affects the functioning of a another filter in the filter chain. Within a filter class, filters are inserted in the order of processing.

NameDescription
UNSPECIFIED

Control plane decides where to insert the filter. Do not specify FilterClass if the filter is independent of others.

AUTHN

Insert filter after Istio authentication filters.

AUTHZ

Insert filter after Istio authorization filters.

STATS

Insert filter before Istio stats filters.

EnvoyConfigObjectMatch

One or more match conditions to be met before a patch is applied to the generated configuration for a given proxy.

FieldDescription
context
PatchContext

The specific config generation context to match on. istiod generates envoy configuration in the context of a gateway, inbound traffic to sidecar and outbound traffic from sidecar.

proxy
ProxyMatch

Match on properties associated with a proxy.

listener
ListenerMatch (oneof)

Match on envoy listener attributes.

routeConfiguration
RouteConfigurationMatch (oneof)

Match on envoy HTTP route configuration attributes.

cluster
ClusterMatch (oneof)

Match on envoy cluster attributes.

EnvoyConfigObjectPatch

Changes to be made to various envoy config objects.

FieldDescription
applyTo
ApplyTo

Specifies where in the Envoy configuration, the patch should be applied. The match is expected to select the appropriate object based on applyTo. For example, an applyTo with HTTP_FILTER is expected to have a match condition on the listeners, with a network filter selection on envoy.filters.network.http_connection_manager and a sub filter selection on the HTTP filter relative to which the insertion should be performed. Similarly, an applyTo on CLUSTER should have a match (if provided) on the cluster and not on a listener.

match
EnvoyConfigObjectMatch

Match on listener/route configuration/cluster.

patch
Patch

The patch to apply along with the operation.

ApplyTo

ApplyTo specifies where in the Envoy configuration, the given patch should be applied.

NameDescription
INVALID
LISTENER

Applies the patch to the listener.

FILTER_CHAIN

Applies the patch to the filter chain.

NETWORK_FILTER

Applies the patch to the network filter chain, to modify an existing filter or add a new filter.

HTTP_FILTER

Applies the patch to the HTTP filter chain in the http connection manager, to modify an existing filter or add a new filter.

ROUTE_CONFIGURATION

Applies the patch to the Route configuration (rds output) inside a HTTP connection manager. This does not apply to the virtual host. Currently, only MERGE operation is allowed on the route configuration objects.

VIRTUAL_HOST

Applies the patch to a virtual host inside a route configuration.

HTTP_ROUTE

Applies the patch to a route object inside the matched virtual host in a route configuration.

CLUSTER

Applies the patch to a cluster in a CDS output. Also used to add new clusters.

EXTENSION_CONFIG

Applies the patch to or adds an extension config in ECDS output. Note that ECDS is only supported by HTTP filters.

BOOTSTRAP

DEPRECATED. Applies the patch to bootstrap configuration.

LISTENER_FILTER

Applies the patch to the listener filter.

PatchContext

PatchContext selects a class of configurations based on the traffic flow direction and workload type.

NameDescription
ANY

All listeners/routes/clusters in both sidecars and gateways.

SIDECAR_INBOUND

Inbound listener/route/cluster in sidecar.

SIDECAR_OUTBOUND

Outbound listener/route/cluster in sidecar.

GATEWAY

Gateway listener/route/cluster.

Was this information useful?
Do you have any suggestions for improvement?

Thanks for your feedback!