Question
Jaeger UI CORS vs Direct Collector Access for Cross-Domain Secure Queries
Rey Indigo
0 reputation · 20 Sept 2020, 23:55 UTC
32.9K views1
Loading…
0 reputation · 20 Sept 2020, 23:55 UTC
Jaeger UI makes API calls to /api/traces using same-origin policy by default. When the UI is served from a different DNS name than the collector endpoint, the browser enforces CORS restrictions that can block query requests.
Two documented approaches exist for resolving this constraint with TLS-secured collector access. Option 1 configures CORS headers on the Query service to allow cross-origin requests from the UI domain. Option 2 uses the --collector.host-port flag to establish direct collector access from the Query service, bypassing DNS resolution and CORS requirements entirely.
The constraint requires maintaining secure TLS connections while ensuring the UI can retrieve trace data. CORS configuration introduces additional header management complexity, whereas direct collector access shifts the resolution dependency to internal service networking.
Which approach better balances security requirements and operational simplicity when Jaeger UI and collector operate under different DNS namespaces with TLS enabled?
--collector.host-port versus standard DNS-based collector discovery?35775 reputation · 21 Sept 2020, 00:36 UTC
Configure CORS on the Jaeger Query service and limit Access-Control-Allow-Origin to the exact UI origin. Do not use --collector.host-port as a substitute for CORS: browser CORS is enforced on the UI→Query API hop, while that flag only changes server-to-server connectivity between Query and collector. Direct collector access does not remove the browser’s same-origin check for UI requests.
| Claim | Assessment | Notes |
|---|---|---|
Browser blocks UI calls to /api/traces across DNS names | Confirmed browser behavior | Same-origin policy applies to the Jaeger UI calling the Query API. |
| CORS headers on Query service resolve the browser block | Confirmed where supported | Releases exposing a CORS allow-origin setting can set it on the Query service; older releases may need a reverse proxy. |
| CORS interacts with TLS termination | Confirmed | CORS is an HTTP response header independent of TLS. Terminate TLS at Query or at the ingress in front of Query, then emit CORS headers on the response. |
--collector.host-port bypasses CORS | Not supported by the architecture | It configures the collector endpoint for server-to-server traffic and does not alter browser enforcement for UI→Query requests. |
| Direct collector access reduces DNS dependency | Confirmed for server-to-server hops | Hardcodes a collector address; collector moves require Query restart or config change and Query must trust the collector TLS certificate. |
jaegertracingJAEGER_QUERY_CORS_ALLOW_ORIGIN=https://ui.example.com, only if your Jaeger release supports it. Avoid wildcard origins for sensitive trace data.--collector.host-port, add the collector CA to the Query truststore; this is separate from the browser CORS fix.Run a scoped preflight check from outside the cluster:
curl -i -X OPTIONS https://query.example.com/api/traces \
-H "Origin: https://ui.example.com" \
-H "Access-Control-Request-Method: GET"Confirm the response includes Access-Control-Allow-Origin: https://ui.example.com and returns a successful status. Then verify a normal trace request returns 200 OK without a browser CORS error.
Is the failure a browser CORS preflight on UI→Query requests, or a Query→collector TLS handshake error? The former is fixed with Query-service CORS; the latter requires certificate trust configuration and is unrelated to CORS.
Assumptions: a recent Jaeger 1.x Query service with CORS configuration support, with TLS terminated at Query or an ingress proxy. Older Jaeger releases may not expose CORS environment variables and may require CORS handling in a reverse proxy instead.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 21 Sept 2020, 02:40 UTC
The browser same-origin check applies to the UI’s calls to /api/traces on jaeger-query, not to Query’s server-to-server connection to the Collector. Because jaeger-query normally serves both the static UI and the query API, CORS is only required when those are split across different origins. If the UI sends cookies or authorization headers, use an exact Access-Control-Allow-Origin value with Access-Control-Allow-Credentials: true; a wildcard origin cannot accompany credentials. Verify in browser devtools by checking the preflight OPTIONS response and the trace request headers.