Filters
Last updated
Was this helpful?
1.2
Last updated
Was this helpful?
The Fabric mesh supports a variety of filters for processing requests received by each listener registered to a Grey Matter Proxy. These filters are used to perform various tasks such as rate limiting, authentication, buffering, health checking, header manipulation, etc.
The purpose of this document is to provide a general overview of how a filter is configured throughout the Fabric mesh.
The Fabric mesh allows for two different types of filters to be configured:
, which operate at the L7 (Application Layer) level.
, which operate at L3/L4 (Network/Transport Layers) levels.
Filter configuration throughout the Fabric mesh is managed via updates to two Control API object types:
, which receives filter configurations and applies them to an individual listener registered to a Grey Matter Proxy.
, which receives filter configurations and applies them to all registered listeners in a Grey Matter Proxy. Note that only HTTP filters may be configured in a Proxy object.
There are several complications to be aware of when configuring multiple filters of either type for a given listener registered to a Grey Matter Proxy.
All Network filters with the exception of one (the Network RBAC filter) are incompatible with HTTP filters configured for the same Listener. This is because Network filters involve recording stats and modifying behavior from raw TCP requests, such as when connecting to a database. If both filter types are configured for the same Listener, downstream traffic will be recorded and modified by both filter types.
To address the need for a service to communicate over both HTTP and TCP, its sidecar should be configured with two Listeners -- one for receiving and directing HTTP traffic, and another for receiving and directing TCP traffic.
Filters process incoming requests along two separate filter chains (e.g. one for active HTTP filters and another for active Network filters). Each filter processes requests in sequential order, meaning that filters configured further down a filter chain will process requests that already have been modified by a number of filters.
In some cases, enabling a filter further down its filter chain may modify or even nullify the behavior of a filter configured further up the chain. These cases are documented as Known Ordering Dependencies in each respective and document.