Envoy 1.39

Apply these rules when configuring Envoy 1.39 listeners, clusters, HTTP filters, and its v3 control-plane APIs. This scope covers the proxy's configuration and security boundaries, not an application's authorization logic or a separate Envoy Gateway deployment.

1. Supported builds and extension trust

• Run the newest patch of an Envoy release line that still receives security fixes. Let the trusted package manager or line-following image tag select the patch, look up the current release, never loosen an existing constraint to make an installation succeed, and audit images and dependencies in CI. Check the running proxy binary, TLS library, and compiled extensions separately from application package audits.
• Start an internet-facing deployment from the documented edge recommendations and size them for its workload. The general defaults suit service meshes and do not establish safe public-edge memory, connection, or timeout budgets.
• Select extensions whose documented security posture covers the actual upstream and downstream trust boundaries. Treat alpha, contrib, deprecated, and custom-build features as requiring separate review; an extension's presence in a binary does not mean the security policy covers hostile traffic to it.
• Treat Lua, Wasm, native dynamic modules, custom validators, and their configuration as privileged code. Do not accept tenant-supplied executable filters or assume their runtimes isolate untrusted code from the proxy's credentials, network, or other tenants.
• Run with a dedicated operating-system identity and minimal capabilities, writable