Currently, Istio places no restrictions on Wasm modules running in Envoy. Wasm modules receive all the data, can write any data, make HTTP calls, or modify the internal filter state. This is not consistent with the principle of the least privilege when dealing with the un-trusted third party code. This is a proposal to add restrictions to Wasm execution by default:

1. Allow the mesh operators to limit the information flow in/out of the modules: an explicit list of callback events to handle: request headers, request body, response headers, response body.
2. Reduce the trusted base in Envoy to hide the less mature/experimental sections of the ABI, and accelerate adoption of the stable parts.

The default capabilities in Wasm can be grouped as follows:

DEFAULT:

• log: ability to emit application logs;
• property read: ability to read attributes (with a possible mask);

BASIC:

• timer: ability to register periodic events;
• metrics: ability to create new metrics;
• side request: ability to make HTTP/gRPC calls;

ADVANCED:

• property write: ability to write attributes;
• store: ability to read/write from shared KV store;
• queue: ability to read/write from shared queues;
• foreign function: ability to invoke host functions;

The logic for grouping is that:

• The default set should be generally safe and recommended.
• The basic set has performance and stability concerns. For example, metrics suffer from the cardinality explosion, and side requests use the mangled xDS names.
• The advanced set is actively discouraged since it is unstable.

cc @ramaraochavali @ingwonsong