Istio's Envoy security update needs a connection limit

A proxy can run out of file descriptors while accepting connections that fit its protocol rules. Istio's June security update addresses that risk by incorporating an Envoy connection limit, but the limit must also be configured. Upgrading supplies the mechanism. An operator has to set a ceiling appropriate for each gateway instance before the disclosed file descriptor exhaustion problem is mitigated.

The June 30 advisory covers four Envoy vulnerabilities affecting Istio 1.5 through 1.5.6 and 1.6 through 1.6.3. It directs users to 1.5.7 or 1.6.4 respectively. Three disclosures concern excessive memory use from crafted traffic. CVE-2020-8663 concerns accepting too many connections and requires additional configuration after the update.

I consider that distinction essential to operating a mesh. A version check can establish that the software contains a defensive mechanism. It cannot establish that the mechanism has an effective value in the running proxy. The advisory provides a procedure for checking that second condition explicitly.

The disclosures exhaust different resources

CVE-2020-12603 concerns excessive memory consumption while proxying crafted HTTP/2 requests or responses. CVE-2020-12605 concerns crafted HTTP/1.1 packets. CVE-2020-12604 describes increased memory use from crafted packets. The advisory groups these with the file descriptor issue because they affect Envoy availability, but they do not share one identical cause or mitigation.

CVE-2020-8663 concerns the number of connections the proxy accepts. The resource at risk is its file descriptor capacity. A connection limit controls admission before accepting an unbounded number of downstream connections. The update exposes that control, and the advisory says it has to be set to mitigate the vulnerability.

That difference prevents a misleading conclusion about the release. Applying the patched Istio version is the stated action for the memory issues, while the connection issue includes an extra operational step. The notice does not say one generic memory or CPU setting resolves all four disclosures. Its connection procedure is specific to the downstream connection mechanism.

The limit spans listeners in one proxy

The Envoy v1.14.3 overload manager documentation identifies the runtime key as overload.global_downstream_max_connections. It limits active downstream connections across all listeners. With no value, there is no global downstream connection limit, and Envoy emits a startup warning.

Global here refers to the listeners of the Envoy process. It does not mean the gateway deployment's replicas share a single connection budget. The Istio advisory tells operators to choose the value according to the concurrent connections needed by individual gateway instances. Adding replicas and selecting a per-instance ceiling are therefore separate decisions.

The Envoy documentation recommends a limit below half of the system's file descriptor limit. Its reason is that upstream connections, open files, and other uses also require descriptors. Counting only downstream connections would leave those consumers out of the budget. The recommendation explains why a connection count cannot simply equal the descriptor ceiling.

This is a resource allocation decision with a visible availability consequence. Once the configured ceiling is reached, the Istio advisory says Envoy rejects TCP connections. A lower ceiling limits the admitted load sooner. A higher ceiling permits more concurrent connections but leaves less protection if it approaches the resources available to that process.

Bootstrap configuration supplies the runtime value

The advisory includes a ConfigMap containing a custom Envoy bootstrap fragment. Its layered runtime configuration has a static layer with the overload setting, followed by an admin layer. The published example uses 250000 connections. That number is sample configuration, not a value justified for every gateway deployment.

A shortened view of the relevant setting is enough to identify its location. This fragment belongs inside the static runtime layer of the supplied bootstrap structure.

{
  "overload": {
    "global_downstream_max_connections": 250000
  }
}

The complete ConfigMap supplied with the disclosure contains the surrounding runtime layers. An operator needs to edit the ceiling for the actual gateway requirements and available descriptors. Copying only the illustrative number does not establish that those requirements have been considered.

The gateway Deployment patch mounts that ConfigMap into istio-proxy. It sets ISTIO_BOOTSTRAP_OVERRIDE to the mounted custom_bootstrap.json file. The environment variable and mount connect the Kubernetes configuration object to the bootstrap input consumed by the proxy.

That connection is important because creating a ConfigMap alone does not make Envoy read it. The Deployment must supply the file at the referenced path. The disclosure's two installation steps therefore express one configuration dependency, the value has to exist and the proxy has to receive it through its bootstrap arrangement.

The running runtime value is the confirmation

The advisory's final step queries the ingress proxy's local admin runtime endpoint on port 15000. Its example output shows the overload key, the layer values, and a final_value of 250000. That checks what the proxy sees after configuration, rather than only inspecting what was intended in Kubernetes YAML.

The layered representation is useful evidence because a configured entry and the final runtime value need not be treated as identical concepts. Both appear in the supplied example. The final value is the relevant observation for determining the ceiling active in the proxy that answered the request.

This procedure is specific to an instance. A successful observation from one gateway pod establishes the state of that pod, not automatically every replica in the deployment. The advisory's per-instance framing remains relevant when applying and checking the configuration across the gateway fleet.

I favor this kind of confirmation because it follows the enforcement path. The ConfigMap records desired input, the Deployment mounts it, and the admin endpoint reports the effective runtime entry. Each observation answers a different question about whether the published mitigation has reached the process accepting connections.

Listener limits and overload actions remain distinct

The Envoy reference also permits limits on individual listeners. Those limits can coexist with the global downstream ceiling and are enforced independently. A smaller per-listener limit can constrain a particular listener while the global value accounts for aggregate downstream use across listeners.

This allows a deployment to distinguish one listener's expected load from the whole proxy's capacity. A per-listener budget alone does not express the same aggregate condition when multiple listeners share a process. The disclosed global setting provides that second constraint.

The setting also counts connections, not HTTP requests per second. Those are different quantities, so a request-rate target does not directly supply a valid connection ceiling. An operator needs the concurrent connection requirement named by the advisory. The distinction follows from the resource being constrained, accepted connections consume descriptors even when application request throughput is not the metric under discussion. The HTTP memory disclosures need their patched implementations as well, because a downstream connection budget does not describe every possible memory cost of processing the traffic on admitted connections.

The overload manager documentation lists other actions, including stopping new request acceptance and disabling HTTP/1 keepalive. It illustrates actions triggered by heap pressure. Those controls operate on a different observation from an explicit count of downstream connections. A heap threshold does not by itself state a file descriptor budget.

That distinction matters when reading an existing bootstrap file. The presence of an overload manager configuration does not prove that the downstream connection ceiling is set. The required evidence for CVE-2020-8663 is the specific configured runtime limit described by the advisory, together with the patched release that supports the mitigation.

The patch and the policy complete different tasks

The branch-specific updates carry the Envoy security corrections into Istio. Configuration then supplies the bound that cannot be selected universally for every installation. Gateway deployments differ in concurrent demand and descriptor availability, so the advisory asks the operator to choose the value instead of presenting its example as a universal default.

The resulting behavior is intentionally restrictive at the chosen ceiling. Rejecting additional TCP connections preserves a finite resource budget, but it also means clients can encounter connection refusal when demand reaches that budget. This is the stated enforcement effect, not an indication that the setting failed to apply.

For this disclosure, completion therefore requires both an updated proxy and a configured downstream limit. The published verification reports the running value inside Envoy. That is the concrete result to establish for the gateway instances accepting traffic, with descriptor capacity left available for the upstream connections and other files identified in Envoy's versioned documentation.