|
| 1 | +syntax = "proto3"; |
| 2 | + |
| 3 | +package envoy.extensions.matching.input_matchers.dynamic_modules.v3; |
| 4 | + |
| 5 | +import "envoy/extensions/dynamic_modules/v3/dynamic_modules.proto"; |
| 6 | + |
| 7 | +import "google/protobuf/any.proto"; |
| 8 | + |
| 9 | +import "udpa/annotations/status.proto"; |
| 10 | +import "validate/validate.proto"; |
| 11 | + |
| 12 | +option java_package = "io.envoyproxy.envoy.extensions.matching.input_matchers.dynamic_modules.v3"; |
| 13 | +option java_outer_classname = "DynamicModulesProto"; |
| 14 | +option java_multiple_files = true; |
| 15 | +option go_package = "github.com/envoyproxy/go-control-plane/envoy/extensions/matching/input_matchers/dynamic_modules/v3;dynamic_modulesv3"; |
| 16 | +option (udpa.annotations.file_status).package_version_status = ACTIVE; |
| 17 | + |
| 18 | +// [#protodoc-title: Dynamic Modules Input Matcher] |
| 19 | +// [#extension: envoy.matching.matchers.dynamic_modules] |
| 20 | + |
| 21 | +// Configuration for the Dynamic Modules Input Matcher. This matcher allows loading shared object |
| 22 | +// files via ``dlopen`` to implement custom matching logic in dynamic modules (e.g. Rust, Go). |
| 23 | +// |
| 24 | +// A module can implement arbitrary matching logic by examining request headers and other HTTP |
| 25 | +// attributes during the match evaluation. This is useful for scenarios that require complex |
| 26 | +// matching beyond what built-in matchers provide, such as JWT/OAuth token analysis, custom |
| 27 | +// routing decisions, or integration with external data sources. |
| 28 | +message DynamicModuleMatcher { |
| 29 | + // Specifies the shared-object level configuration. This field is required. |
| 30 | + envoy.extensions.dynamic_modules.v3.DynamicModuleConfig dynamic_module_config = 1 |
| 31 | + [(validate.rules).message = {required: true}]; |
| 32 | + |
| 33 | + // The name for this matcher configuration. If not specified, defaults to an empty string. |
| 34 | + // |
| 35 | + // This can be used to distinguish between different matcher implementations inside a dynamic |
| 36 | + // module. For example, a module can have completely different matcher implementations (e.g., |
| 37 | + // OAuth token matcher, geo-IP matcher). When Envoy receives this configuration, it passes |
| 38 | + // the ``matcher_config_name`` to the dynamic module's matcher config init function together |
| 39 | + // with the ``matcher_config``. That way a module can decide which in-module matcher |
| 40 | + // implementation to use based on the name at load time. |
| 41 | + string matcher_config_name = 2; |
| 42 | + |
| 43 | + // The configuration for the matcher chosen by ``matcher_config_name``. If not specified, an |
| 44 | + // empty configuration is passed to the module. |
| 45 | + // |
| 46 | + // This is passed to the module's matcher initialization function. Together with the |
| 47 | + // ``matcher_config_name``, the module can decide which in-module matcher implementation to |
| 48 | + // use and fine-tune the behavior of the matcher. |
| 49 | + // |
| 50 | + // ``google.protobuf.Struct`` is serialized as JSON before passing it to the module. |
| 51 | + // ``google.protobuf.BytesValue`` and ``google.protobuf.StringValue`` are passed directly |
| 52 | + // without the wrapper. |
| 53 | + google.protobuf.Any matcher_config = 3; |
| 54 | +} |
0 commit comments