Introduction

In Istio, HTTP header logging is usually implemented by customizing Envoy access log format so specific request or response headers are written into the access log. There is no safe "log every header everywhere" switch you should enable blindly, because headers often contain tokens, cookies, and other sensitive data.

Log specific headers through access log format

Envoy access logs support format operators such as %REQ(header-name)% for request headers and %RESP(header-name)% for response headers. In Istio, these are typically configured through mesh-level access log settings.

1meshConfig:
2  accessLogFile: /dev/stdout
3  accessLogFormat: |
4    [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" 
5    %RESPONSE_CODE% request_id=%REQ(x-request-id)% user_agent=%REQ(user-agent)%

This example logs the request ID and user agent without dumping the full header set.

Apply the configuration through Istio control-plane configuration

If you manage Istio with an operator-style manifest, place the log settings in the control-plane configuration and apply them with istioctl.

1apiVersion: install.istio.io/v1alpha1
2kind: IstioOperator
3spec:
4  meshConfig:
5    accessLogFile: /dev/stdout
6    accessLogFormat: |
7      [%START_TIME%] %REQ(:METHOD)% %REQ(:PATH)% request_id=%REQ(x-request-id)%

istioctl install -f istio-logging.yaml

After rollout, proxy access logs will include the selected header values.

Inspect the proxy logs from a workload

Once deployed, check the sidecar logs for a specific pod.

kubectl logs deploy/my-service -c istio-proxy

If the custom header values do not appear, verify that the request actually includes the header and that the field name matches Envoy's expected spelling.

Use EnvoyFilter only when simpler mesh config is not enough

EnvoyFilter can patch low-level proxy configuration, but it is more brittle than using supported Istio configuration surfaces. For ordinary header access logging, mesh-level access log settings are usually enough. Reach for EnvoyFilter only when you need very targeted behavior that the higher-level API cannot express.

This matters because EnvoyFilter is easier to break across Istio upgrades and harder to reason about during troubleshooting.

Avoid logging sensitive headers

Before adding headers to logs, review whether they can contain secrets or personally identifiable data. Logging Authorization, session cookies, or internal identity headers can create a much bigger operational problem than the debugging issue you started with.

A good pattern is to log only the few headers that directly support traceability, such as x-request-id, x-b3-traceid, or a safe custom business identifier.

Verify requests with a test header

You can test the configuration by sending a known header through the proxy.

curl -H 'x-request-id: debug-123' http://my-service.default.svc.cluster.local/

Then inspect the istio-proxy logs and confirm that debug-123 appears in the access log line.

Log response headers only when they are truly needed

Request headers are usually enough for tracing, but Envoy can also log response headers with operators such as %RESP(server)%. Use that sparingly, because it increases noise quickly and often adds less value than expected.

Common Pitfalls

• Looking for a global "log all headers" switch instead of configuring access log format explicitly.
• Using EnvoyFilter for a simple access-log change that mesh config could handle more safely.
• Logging sensitive headers such as Authorization or cookies into shared log sinks.
• Forgetting to inspect the sidecar container logs instead of the application container logs.
• Misspelling header names in Envoy format expressions and assuming the feature is broken.

Summary

• In Istio, header logging usually means customizing Envoy access log format.
• Log only the specific headers you need with operators such as %REQ(x-request-id)%.
• Prefer supported mesh configuration over low-level EnvoyFilter patches when possible.
• Check istio-proxy logs to verify the change.
• Be deliberate about privacy and avoid logging sensitive headers.