The ServiceMeshExtension
custom resource spec provides the configuration that the Proxy-WASM
module reads from.
The spec is embedded in the host and read by the Proxy-WASM
module. Typically, the configurations are in the JSON file format for the modules to parse, however the ServiceMeshExtension
resource can interpret the spec value as YAML and convert it to JSON for consumption by the module.
If you use the Proxy-WASM
module in stand-alone mode, you must write the configuration using the JSON format. Using the JSON format means using escaping and quoting where needed within the host
configuration files, for example Envoy
. When you use the WebAssembly module with the ServiceMeshExtension
resource, the configuration is in the YAML format. In this case, an invalid configuration forces the module to show diagnostics based on its JSON representation to a sidecar’s logging stream.
|
The EnvoyFilter custom resource is not a supported API, although it can be used in some 3scale Istio adapter or Service Mesh releases. Using the EnvoyFilter custom resource is not recommended. Use the ServiceMeshExtension API instead of the EnvoyFilter custom resource.
If you must use the EnvoyFilter custom resource, you must specify the spec in JSON format.
|
Configuring the 3scale WebAssembly module
The architecture of the 3scale WebAssembly module configuration depends on the 3scale account and authorization service, and the list of services to handle.
Prerequisites
The prerequisites are a set of minimum mandatory fields in all cases:
-
For the 3scale account and authorization service: the backend-listener
URL.
-
For the list of services to handle: the service IDs and at least one credential look up method and where to find it.
-
You will find examples for dealing with userkey
, appid
with appkey
, and OpenID Connect (OIDC) patterns.
-
The WebAssembly module uses the settings you specified in the static configuration. For example, if you add a mapping rule configuration to the module, it will always apply, even when the 3scale Admin Portal has no such mapping rule. The rest of the ServiceMeshExtension
resource exists around the spec.config
YAML entry.
The 3scale WebAssembly module api object
The api
top-level string from the 3scale WebAssembly module defines which version of the configuration the module will use.
|
A non-existent or unsupported version of the api object renders the 3scale WebAssembly module inoperable.
|
The api
top-level string example
apiVersion: maistra.io/v1
kind: ServiceMeshExtension
metadata:
name: threescale-wasm-auth
namespace: bookinfo
spec:
config:
api: v1
...
The api
entry defines the rest of the values for the configuration. The only accepted value is v1
. New settings that break compatibility with the current configuration or need more logic that modules using v1
cannot handle, will require different values.