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 filter is missing in these CRs, the CR EnvoyHTTPFilter can be used to prepend such a native Envoy filter. The CR EnvoyCluster allows configuring additional clusters if a native Envoy 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 filters that connect to an upstream service require configuring the corresponding cluster with CR EnvoyCluster.
  • Envoy filters that do their work without an external cluster do not need an EnvoyCluster configured.

Example configuration

The CR EnvoyHTTPFilter allows configuring additional native Envoy filters of kind httpFilters with their full functionality.

  • The following example shows a simple CustomResource EnvoyHTTPFilter which configures the following:
  • The httpFilter ext_authz communicates with the cluster ext-authz.
copy
apiVersion: microgateway.airlock.com/v1alpha1 
kind: EnvoyHTTPFilter 
metadata: 
  name: ext-filter-1 
spec: 
  value: 
    name: envoy.filters.http.ext_authz  
    typed_config:  
      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz  
      http_service:  
        path_prefix: "/auth/login"  
        server_uri:  
          uri: http://opa.service.internal:8099  
          cluster: ext-authz  
          timeout: 0.25s

The native Envoy 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 Envoy HTTP filters for further information.

It is highly recommended to use the CRs EnvoyHTTPFilter and EnvoyClusters only if the feature is unavailable in our other CRs. In such cases, please create a support case and let us know the use case and which feature you are missing in our CRs.

See also the API Reference documentation link at the end of this article.

Reference in CR SidecarGateway

To apply a certain EnvoyHTTPFilter CR for a specific Microgateway Engine, it must be referenced in the corresponding SidecarGateway. The following example references two EnvoyHTTPFilters.

copy
apiVersion: microgateway.airlock.com/v1alpha1
kind: SidecarGateway
metadata:
  name: my-sidecar-gateway
spec:
  ...
  ...
  routes:
    - containerPort: 8090
      ...
      envoyHTTPFilterRefs:
        prepend:
          - name: ext-filter-1
          - name: ext-filter-2

The custom Envoy filters defined in envoyHTTPFilterRefs.prepend are applied before the Microgateway Engine filters in the order they appear in the SidecarGateway.

Referencing multiple CustomResources can be useful when integrating shared services like an external authorization service by reusing service integration configurations from different SidecarGateways.

See also the API Reference documentation link at the end of this article.