-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secure tracing data to Jaeger backend #8897
Comments
Copy and paste Jim's comment from email: To summarize, we agreed to going ahead with UDP for the beta but before we approve this for GA, we need to look at securing this better. Two options we discussed:
Jim |
(1) yes, but varies by language |
@yurishkuro We are having concerns on the unsecured connection between client and agent. Does the Java client support https calls to the collector? |
|
@yurishkuro Does it work for Java? If yes, do you have pointers to the documentation? |
I assume you can specify https as JAEGER_URL. But collector itself doesn't run https server iirc so you'd need to put a proxy in front of it. |
jaegertracing/jaeger-client-java#602 hasn't been merged yet so I guess the client can't send https directly to collector yet. |
That PR adds client cert validation, if you need it for client auth. If you're only concerned with transport security, then https should already be supported. |
Successfully setup a nginx https reverse proxy in front of jaeger-controller and I was able to use a https endpoint in jaeger-client. |
Jim Mulvey, Ajay Reddy, Chunlong Liang and Felix Wong had a meeting on 9/09/2019 to discuss how to secure the tracing data from Jaeger Client to Jaeger backend.
Since the data transfer between Jaeger Client and Agent is using unsecure UDP, we agreed this is acceptable to go out as is as a beta.
For GA, we need to find a more secure solution.
Jim found a git issue on Jaeger security:
jaegertracing/jaeger#1718
And it has a link to this article.
https://medium.com/@larsmilland01/secure-architecture-for-jaeger-with-apache-httpd-reverse-proxy-on-openshift-f31983fad400
The text was updated successfully, but these errors were encountered: