CR EnvoyHTTPFilter
The Envoy proxy is the basis for the Microgateway Engine. It has been enriched with Airlock-specific features which can be configured with the corresponding CRs. If a feature available as a native Envoy HTTP filter is missing in these CRs, the CR EnvoyHTTPFilter can be used to prepend such a native Envoy HTTP filter. The CR EnvoyCluster allows configuring additional clusters if a native Envoy HTTP filter relies on it. For the CRs EnvoyHTTPFilter and EnvoyCluster, the Envoy configuration language must be used.
When do I have to configure an EnvoyCluster?
- Envoy HTTP filters that connect to an upstream service require configuring the corresponding cluster with CR EnvoyCluster.
- Envoy HTTP filters that do their work without an external cluster do not need an
EnvoyClusterconfigured.
You should use the CRs EnvoyHTTPFilter and EnvoyClusters only if a feature is unavailable in our other CRs. In such cases, contact our Support and let us know the use case and which feature you are missing in our current CRs.
Example configuration
For the default and an example configuration, see CR EnvoyHTTPFilter reference documentation.
The example covers:
- Configuration of the native Envoy HTTP filter
ext_authzwhich communicates with the clusterext-authz.
The native Envoy HTTP filter and cluster are defined in the value section in raw types. The Microgateway Operator validates only the YAML syntax and if the input can be unmarshalled to the corresponding proto type.
Consult the Envoy documentation Official Envoy HTTP filters documentation for further information.