Ingress-nginx: Forward X-Request-ID to auth service

[rittneje]

When specifying an auth service via the nginx.ingress.kubernetes.io/auth-url annotation, the X-Request-ID header should get forwarded along. If this header was not specified in the original request, the auto-generated $request_id variable should be sent in its place. This already happens for the actual backend service. However, we would like it to also be sent to the auth service so we can properly trace the entire request.

Currently we can work around this by manually setting the header ourselves. But it is annoying that this behavior isn't the default.

    nginx.ingress.kubernetes.io/auth-snippet: |
      proxy_set_header X-Request-ID $req_id;

/kind feature

[ElvinEfendi]

IMHO we should not be passing X-Request-Id as is from the parent request (client request). When doing an external authentication NGINX initiates a _new_ request to the auth server, it is not the same request as the original client request. If you want to relate the two, a better approach would be to pass the original request id as X-Parent-Request-Id.

[rittneje]

@ElvinEfendi I completely disagree. You are just making it needlessly complicated. It is all being done as part of the same request. Plus, what happens if the auth service itself makes some external call? Now it needs to forward both headers.

[ElvinEfendi]

Plus, what happens if the auth service itself makes some external call? Now it needs to forward both headers

This is why people created distributed tracing. Misusing Request ID like that is not a solution for distributed tracing.

[rittneje]

The reason for request ids is so that if something goes wrong, I can easily fetch all the logs pertaining to that particular request. Consequently, if it isn't passed to each backend service involved in the processing of that particular request, then it is of extremely limited utility. Meanwhile, true distributed tracing is more focused on monitoring performance issues and other statistics aggregated across requests, and not necessarily on diagnosing issues with _specific_ requests.

With your solution, I inevitably would have to log the mapping from original request id to child request id so I can properly debug. That makes it even more difficult, since I have to recursively search for the new request id each time another service is hit. And it has no benefits whatsoever.

In short, passing request id along is not a misuse. It is what you are supposed to be doing.

[ngocketit]

This doesn't seem to work with Istio. When doing external auth, ingress-nginx makes a new request to auth service with a new request id which is generated by Envoy sidecar.