Mapped Attribute Builder for the external processor (proto)

This extension has the qualified name envoy.http.ext_proc.processing_request_modifiers.mapped_attribute_builder

Note

This extension is work-in-progress. Functionality is incomplete and it is not intended for production use.

This extension has an unknown security posture and should only be used in deployments where both the downstream and upstream are trusted.

Tip

This extension extends and can be used with the following extension category:

This extension must be configured with one of the following type URLs:

Warning

This API feature is currently work-in-progress. API features marked as work-in-progress are not considered stable, are not covered by the threat model, are not supported by the security team, and are subject to breaking changes. Do not use this feature without understanding each of the previous points.

extensions.http.ext_proc.processing_request_modifiers.mapped_attribute_builder.v3.MappedAttributeBuilder

[extensions.http.ext_proc.processing_request_modifiers.mapped_attribute_builder.v3.MappedAttributeBuilder proto]

Extension to build custom attributes in the ProcessingRequest based on a configurable mapping. The native implementation uses the CEL expression as the key, which is not always desirable. Using this extension, one can re-map a CEL expression that references internal filter state into a more user-friendly key that decouples the value from the underlying filter implementation.

If a given CEL expression fails to evaluate, it will not be present in the attributes struct.

If this extension is configured, then the original ProcessingRequest’s request_attributes are ignored, and all attributes should be explicitly set via this extension.

An example configuration may look like so:

mapped_request_attributes:
  "request.path": "request.path"
  "source.country": "metadata.filter_metadata['com.example.location_filter']['country_code']"

In the above example, the complex filter_metadata expression is evaluated via CEL, and the value is stored under the friendlier source.country key. The ProcessingRequest would look like:

attributes {
  key: "envoy.filters.http.ext_proc"
  value {
    fields {
      key: "request.path"
      value {
        string_value: "/profile"
      }
    }
    fields {
      key: "source.country"
      value {
        string_value: "US"
      }
    }
  }
}

Note

Processing request modifiers are currently in alpha.

{
  "mapped_request_attributes": {...},
  "mapped_response_attributes": {...}
}
mapped_request_attributes

(repeated map<string, string>) A map of request attributes to set in the attributes struct. The key is the attribute name, and the value is the CEL expression to evaluate. This allows for the re-mapping of attributes, which is not supported by the native attribute building logic.

mapped_response_attributes

(repeated map<string, string>) Similar to mapped_request_attributes, but for response attributes. The “response” nomenclature here indicates that the attributes, whatever they may be, are sent with a response headers, body, or trailers ext_proc call.

If a value contains a request key (e.g., request.host), then the attribute would just be sent along in the response. This is useful if a given ext_proc extension is only enabled for response handling (e.g., RESPONSE_HEADERS) but the backend wants to access request metadata.