-
|
I have access logging enabled. All inbound http(s) connections log path, method, and response code. But for outbound https connections path and method are null and response code is always 0. The upstream_cluster was showing passthroughcluster, so since the requests are encrypted I understand that these fields are not available. However, I thought that if I configured the side car to terminate the TLS session and re-originate the request that I would be able to capture these fields. I did this by creating a service entry and a destination rule. Unfortunately this had no effect on the logging. I noticed tho that the upstream cluster field no longer contains the passthroughcluster value but rather an envoy style cluster name of outbound|443||hostname. This seems to indicate that the sidecar is infact terminating and re-originating the request. Based on how things log tho, it seems like there should be a seperate log entry for the newly originated connection, and maybe this is where I could see the path, method, and response code for the outbound https traffic. Am I missing some setting that would control whether or not this "extra hop" would log? Or am I just approaching this problem wrong? I really need to be able to log path, method, and response code for outbound https calls to external services. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
There is always 1 log to express the 2 connections (client --> envoy --> destination), even in envoy is terminating + re-originating. But if envoy is receiving http it should log all of those things? Maybe you could show the current log. |
Beta Was this translation helpful? Give feedback.
-
|
It turns out that this is not possible at least as far as I can tell. There might be some hack that could work out there. The issue is that the app inside the pod is opening an SSL connection to the outside world. The sidecar cannot terminate it and re-originate because it would need a certificate that matched the target host to do so. This can however be done if the pod initiates a plain HTTP connection. The sidecar can terminate that and then re-orginate it as HTTPS to the target. Then everything gets logged as expected. |
Beta Was this translation helpful? Give feedback.
It turns out that this is not possible at least as far as I can tell. There might be some hack that could work out there. The issue is that the app inside the pod is opening an SSL connection to the outside world. The sidecar cannot terminate it and re-originate because it would need a certificate that matched the target host to do so. This can however be done if the pod initiates a plain HTTP connection. The sidecar can terminate that and then re-orginate it as HTTPS to the target. Then everything gets logged as expected.