Add enableContextPropagation field to Telemetry Tracing API

[prashanthjos]

Description

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

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 enableContextPropagation (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:
  - enableContextPropagation: false

fixes #58871

[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.

[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.