Description
(This is used to request new product features, please visit https://github.com/istio/istio/discussions for questions on using Istio)
Describe the feature request
As identified in GHSA-ffhv-fvxq-r6mf, Envoy previously considered all private IPs as internal by default. If an address was "internal", the x-envoy header would not be sanitized on inbound or outbound. This vulnerability unintentionally enabled implicit trust of private IPs allowing external clients to configure envoy headers if the requests passed through an ingress gateway. Internally (sidecar to sidecar requests originating in the mesh), internal envoy headers are stripped as long as the useRemoteAddress is false and the XFF header is unset. However, from Envoy's perspective the set of trusted IP addresses by default is still the set of all private IPs.
To better align with the zero-trust model, Istio should configure Envoy to untrust all IP addresses by default when determining whether internal Envoy headers should be sanitized on inbound/outbound. Users should be able to opt sidecars into trusted mode where internal Envoy headers are not sanitized on outbound. Additionally, Istio should provide a mechanism for users to configure the set of trusted IP address, the internalAddressConfig. Currently, a mechanism via the Istio API does not exist to granularly configure a pod or mesh-wide internalAddressConfig. Through the proxyConfig a user can enable and disable implicit trust of all private IPs.
TODO:
- Add release note for Istio 1.25 explaining the default envoy behavior change and document how to disable
explicit_internal_address_configto revert to previous behavior. Link to documentation on how to enableENABLE_HCM_INTERNAL_NETWORKSto set the internal address config.Add documentation on configuring mesh networks with respect toENABLE_HCM_INTERNAL_NETWORKS
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[ ] Dual Stack
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[x] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Activity
jaellio commentedon Oct 21, 2024
In Envoy v1.33, users must explicitly configure the
internal_address_confighttps://github.com/envoyproxy/envoy/releases/tag/v1.32.0. Currently, in v1.32 and all prior versions, the defaultinternal_address_configis the set of all private IPs.internal_address_configon HttpConnectionManager explicitly kumahq/kuma#12190jaellio commentedon Jan 22, 2025
For Envoy's 1.33 release,
explicit_internal_address_configwill default totrue. To revert to the old behavior of trusting all internal IPs as internal Istio users can setexplicit_internal_address_configtofalsein the mesh or proxy configs. This behavior will impact Istio 1.25.As of now, I am not planning on adding support to configure the internal address config via an EnvoyFilter or other Istio custom resource. If we receive user requests for adding this capability we will consider adding support in future releases.
ramaraochavali commentedon Jan 25, 2025
It is already supported. You can enable ENABLE_HCM_INTERNAL_NETWORKS to true and create a Mesh Network with the internal IP addresses, it will automatically create an InternalAddressConfig and set it to Envoy.
jaellio commentedon Jan 27, 2025
@ramaraochavali That's a good point. We're already leveraging that logic to support internal address configuration when
PILOT_SIDECAR_USE_REMOTE_ADDRESSis enabled. IsENABLE_HCM_INTERNAL_NETWORKSexperimental and if so, are there plans to promote it? Are there examples for configuring mesh networks with respect to also enablingENABLE_HCM_INTERNAL_NETWORKS. We should at least add explicit work around steps when we document this envoy behavior change in the next Istio release.ramaraochavali commentedon Jan 28, 2025
It is off by default because of production usage. If more folks use, we can enable it as true for couple of releases and default it.
Unfortunately no.
Sure. We can do