Clarified consumer-to-query security support. #522
Conversation
Signed-off-by: Travis Illig <tillig@paraesthesia.com>
content/docs/1.22/security.md
Outdated
| @@ -38,7 +38,7 @@ Clients can be configured to communicate directly with the Collector via HTTP. U | |||
|
|
|||
| ## Consumers to Query Service | |||
|
|
|||
| * {{< check_yes >}} HTTP - no TLS/authentication. | |||
| * {{< check_yes >}} gRPC - no TLS/authentication. | |||
| * {{< check_yes >}} HTTP - TLS supported, no authentication supported. | |||
There was a problem hiding this comment.
Forgive my ignorance as I don't know much about TLS; I thought authentication is built into TLS?
There was a problem hiding this comment.
TLS is about encrypting the communication channel, not proving you are who you say you are. mTLS (mutual TLS) has authentication built in because it involves an exchange of client certificates.
Think about it like this - you visit https://www.amazon.com from your browser. That's using TLS, but Amazon doesn't know who you are until you authenticate (e.g., username + password). Same principle here.
There was a problem hiding this comment.
Ah, thanks for that explanation, I didn't know about mTLS, but did a bit of reading about it; I guess with TLS, the server is authenticated, but not the client, and this is the gap that mTLS fills.
How did you determine that HTTP doesn't support mTLS?
I was looking at the source code and I think here is where we enable the RequireAndVerifyClientCert flag (mTLS).
IIUC it looks like that RequireAndVerifyClientCert flag is enabled when the .tls.client-ca option is enabled, and the initialization of these flags appear to be done for both gRPC and HTTP in the query service.
It's quite likely I'm misunderstanding something though.
There was a problem hiding this comment.
I was going by the latest comment on the related issue since I mentioned I don't actually know the answer. If I need to fix it, please do let me know. We're outside my Go + Jaeger source expertise here.
There was a problem hiding this comment.
I agree, I think both gRPC and HTTP servers now support mTLS. I closed #2249.
There was a problem hiding this comment.
Is that as of 1.22? I want to make sure I update the right version(s).
Signed-off-by: Travis Illig <tillig@paraesthesia.com>
|
lgtm, thanks @tillig!
|
| @@ -38,7 +38,7 @@ Clients can be configured to communicate directly with the Collector via HTTP. U | |||
|
|
|||
| ## Consumers to Query Service | |||
|
|
|||
| * {{< check_yes >}} HTTP - no TLS/authentication. | |||
| * {{< check_yes >}} gRPC - no TLS/authentication. | |||
| * {{< check_yes >}} HTTP - TLS with client cert authentication supported. | |||
There was a problem hiding this comment.
maybe we could use the same text as for Cassandra above: "TLS with mTLS supported"
There was a problem hiding this comment.
I was using the same text from the Agent to Collector section for gRPC. Should I switch them all to "TLS with mTLS supported" ?
|
I don't mind fixing |
|
no worries, good as is. Thanks! |
Signed-off-by: Travis Illig tillig@paraesthesia.com
Which problem is this PR solving?
Resolves #475
Short description of the changes
Clarification on what is supported for encryption and authentication in collector-to-query communications. Previously the green checkmark indicated there was support but the text was inconsistent with that; this resolves the ambiguity.