Add disableContextPropagation field to Telemetry Tracing API

[prashanthjos]

Description

This PR adds a new disableContextPropagation field to the Telemetry API's Tracing configuration.

fixes #58871

Problem

Currently, there is no way to disable trace context propagation without also disabling span reporting. Users who want to prevent trace headers from being forwarded to external services (e.g., at egress gateways) must use workarounds like:

1. Setting disableSpanReporting: true (which loses observability)
2. Using VirtualService header manipulation (which doesn't work when spans are still being reported)

Solution

Add disableContextPropagation (defaults to true) to the Tracing config. When set to false:

• Trace context headers (X-B3-*, traceparent, tracestate, etc.) are not propagated in forwarded requests
• Span reporting continues normally (unaffected)

Example Usage

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: egress-no-propagation
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: egressgateway
  tracing:
  - disableContextPropagation: false
  ```

### Use Case
- Istio mesh with egress gateway routing all external traffic
- Full tracing enabled inside the mesh
- Prevent leaking trace context headers to 3rd-party external services
- Maintain span reporting from egress gateway for internal observability

### Changes
- Added enable_context_propagation field (field number 9) to Tracing message in telemetry/v1alpha1/telemetry.proto
- Added documentation example for egress gateway use case

### Affected Areas
- Extensions and Telemetry
- Security (prevents information leakage)
- User Experience
- Docs

[zirain]

how would this work? can you elaborate?

[prashanthjos]

@zirain this is my current thought process, do let me know if you see any issue:

Since Envoy's tracing providers don't have a native "disable propagation" option, the implementation in istiod would need to:

1. Add EnableContextPropagation field to TracingSpec in pilot/pkg/model/telemetry.go

2. When enableContextPropagation: false, add route-level request header removal for trace context headers before forwarding upstream:

   • X-B3-TraceId, X-B3-SpanId, X-B3-ParentSpanId, X-B3-Sampled, X-B3-Flags (Zipkin/B3)
   • traceparent, tracestate (W3C/OpenTelemetry)
   • Potentially x-request-id

This is similar to how VirtualService header manipulation works, but applied automatically based on the Telemetry config. Tracing remains enabled (spans are reported), but the headers are stripped before the request leaves the proxy. I will dive deeper once I get to implementation.

[zirain]

so that means a Telemetry API will affect route?

[prashanthjos]

Yes, the Telemetry API would affect route configuration when enableContextPropagation: false. ( I will get better idea once I start coding the changes, but this is the idea for now)

Since Envoy's tracing providers don't have a native "disable propagation only" option (they always propagate headers when tracing is enabled), the implementation would need to add request header removal to the route config to strip trace context headers before forwarding upstream.

This is similar to how:

• disableSpanReporting affects whether tracing is configured at all
• Access logging Telemetry config affects listener/HCM filters

The Telemetry API already influences multiple parts of Envoy config (HCM tracing, filters, etc.). This would extend that to route-level header manipulation when context propagation needs to be disabled.

[zirain]

They wouldn't change the route, accesslog is a part of HCM.

Then I would like to say no to this API, recommand to add tips on istio.io before envoy support native dsiable context propagtion base on the tracing provider.

[prashanthjos]

@zirain are you suggesting changes to envoy, before making Istio changes?

[zirain]

@zirain are you suggesting changes to envoy, before making Istio changes?

Yes, that's what I thought.

[prashanthjos]

I understand, let me see if I can try making changes to envoy before moving forward.

[prashanthjos]

@zirain the PR has been approved by Envoy, we now have no_context_propogation option available in envoy

envoyproxy/envoy#43324

[prashanthjos]

@zirain looks like your approval is not merging the PR, how can we get this merged :)

[zirain]

we need a TOC approve.

[prashanthjos]

@ramaraochavali @keithmattix @therealmitchconnors can you please help

[istio-policy-bot]

🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?

Courtesy of your friendly test nag.

[ramaraochavali]

Should we change this to disable_context_propagation to align with disable_span_reporting and also aligns with existing default (which is enabled by default) so there is no special logic in code to default it to true?
cc: @zirain

[zirain]

I was thinking align with enable_istio_tags, but either is fine to me.

[ramaraochavali]

Ok. It seems logical to align with span reporting as they are related and easy to understand

[zirain]

SGTM

[prashanthjos]

hmm I agree, we can rename, @ramaraochavali shall I rename this to disable_context_propagation ? It aligns with envoy no_context_propogation

[ramaraochavali]

yes

[prashanthjos]

@ramaraochavali I have updated the code with the changes.