Skip to content

Clarify relationship btw MeshNetworks and ENABLE_HCM_INTERNAL_NET #3433

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 19, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions mesh/v1alpha1/istio.mesh.v1alpha1.pb.html

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

15 changes: 15 additions & 0 deletions mesh/v1alpha1/network.pb.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

15 changes: 15 additions & 0 deletions mesh/v1alpha1/network.proto
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,21 @@ message Network {
// locality: us-east-1a
// ```
//
// If `ENABLE_HCM_INTERNAL_NETWORKS` is set to true, MeshNetworks can be used to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we need an example of how to do this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If Networks defaults to all mesh IPs then maybe not, but I need to clarify the default value of Networks

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my quick investigation, I don't think there is a default Network configured. I had previously thought it defaulted to all mesh IPs. @ramaraochavali Since you are more familiar with this configuration could confirm this and review an additional example?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I the documentation is correct. But I would hesitate to add the temporary feature flag reference here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we update this documentation when the feature flag is removed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But nothing is changed in network API. So not sure why we have to update here. Why is n't the main istio release notes not sufficient?

Copy link
Contributor Author

@jaellio jaellio Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked having the information here so it would be clearly displayed in our api docs on istio.io. Otherwise, the only documentation on how to utilize MeshNetworks to preserve envoy internal headers. I could modify/simplify the description and link to the upgrade note?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think specifying MeshNetworks can also be used to define "internal" addresses of mesh and provide an example is fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @jaellio that the feature flag + example is useful//necessary here. Users who run into the Envoy behavior change are going to come to Istio documentation to tell them what to do. We should have a clear answer for them

// to explicitly define the networks in Envoy's internal address configuration.
// Envoy uses the IPs in the `internalAddressConfig` to decide whether or not to sanitize
// Envoy headers. If the IP address is listed an internal, the Envoy headers are not
// sanitized. As of Envoy 1.33, the default value for `internalAddressConfig` is set to
// an empty set. Previously, the default value was the set of all private IPs. Setting
// the `internalAddressConfig` to all private IPs (via Envoy's previous default behavior
// or via the MeshNetworks) will leave users with an Istio Ingress Gateway potentially
// vulnerable to `x-envoy` header manipulation by external sources. More information about
// this vulnerability can be found here:
// https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf
// To preserve headers, you must explicitly configure MeshNetworks and set
// `ENABLE_HCM_INTERNAL_NETWORKS` to true. Envoy's `internalAddressConfig` will be set to
// the endpointed specified by `fromCidr`.
//
message MeshNetworks {
// The set of networks inside this mesh. Each network should
// have a unique name and information about how to infer the endpoints in
Expand Down
16 changes: 16 additions & 0 deletions releasenotes/notes/mesh-network-internal-addr-config.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
apiVersion: release-notes/v2
kind: bug-fix
area: documentation
issue:
- https://github.com/istio/istio/issues/53402

releaseNotes:
- |
**Fixed** documentation for using MeshNetworks to configure envoy internal address configuration
when ENABLE_HCM_INTERNAL_NETWORKS is set to true. As of Envoy 1.33, the default value for
internalAddressConfig is set to an empty set. Previously, the default value was the set of all
private IPs. To preserve Envoy headers, you must explicitly configure MeshNetworks
or revert to Envoy's prior behavior by setting envoy.reloadable_features.explicit_internal_address_config
to false. Setting MeshNetworks to all private IPs or reverting to Envoy's previous behavior will leave
users with an Istio Ingress Gateway potentially vulnerable to x-envoy header manipulation by external
sources. More information about this vulnerability can be found here: https://github.com/envoyproxy/envoy/security/advisories/GHSA-ffhv-fvxq-r6mf