-
Notifications
You must be signed in to change notification settings - Fork 765
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
OtlpExporter: Integration test testing https support #1795
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1795 +/- ##
==========================================
- Coverage 79.71% 79.70% -0.02%
==========================================
Files 254 254
Lines 8404 8404
==========================================
- Hits 6699 6698 -1
- Misses 1705 1706 +1
|
{ | ||
throw new NotSupportedException("Https Endpoint is not supported."); | ||
throw new NotSupportedException($"Endpoint URI scheme ({options.Endpoint.Scheme}) is not supported."); | ||
} | ||
|
||
#if NETSTANDARD2_1 | ||
this.channel = GrpcChannel.ForAddress(options.Endpoint); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From https://docs.microsoft.com/en-us/aspnet/core/grpc/client?view=aspnetcore-5.0#configure-tls
To configure a gRPC channel to use TLS, ensure the server address starts with https. For example, GrpcChannel.ForAddress("https://localhost:5001") uses HTTPS protocol. The gRPC channel automatically negotiates a connection secured by TLS and uses a secure connection to make gRPC calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good.
Not explicitly approving, as we are trying to add integration test for secure connection
@pjanotti @CodeBlanch @reyang @pcwiese Please help review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
ChannelCredentials channelCredentials; | ||
if (options.Endpoint.Scheme == Uri.UriSchemeHttps) | ||
{ | ||
channelCredentials = new SslCredentials(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So those that want a secure channel I guess would specify the cert path via the environment variable? If so this seems like it would work for the simple case. I hope the additional tests prove this out and this gets into 1.0!
LGTM also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://grpc.github.io/grpc/csharp/api/Grpc.Core.SslCredentials.html#Grpc_Core_SslCredentials__ctor
We shouldn't recommend customers to rely on this env variable. Its an implementation detail that it works, so they shouldn't bet on it.
Instead, the actual environment variable, as per otel spec should be added in 1.1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpTraceExporter.cs
Outdated
Show resolved
Hide resolved
src/OpenTelemetry.Exporter.OpenTelemetryProtocol/OtlpTraceExporter.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Paulo Janotti <pjanotti@splunk.com>
…emetry-dotnet into alanwest/otlp-allow-tls
test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/Dockerfile
Outdated
Show resolved
Hide resolved
// TODO: Should test both http and https | ||
Endpoint = new System.Uri($"https://{CollectorEndpoint}"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to vet out https support, I just changed the test to use https. I plan to follow up and have it test both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use a self-signed cert might need to manually pass validation somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use a self-signed cert might need to manually pass validation somehow?
The cert gets installed as a trusted cert here, so no need to manually pass validation:
opentelemetry-dotnet/test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/Dockerfile
Lines 18 to 20 in 21bed21
RUN apt-get update && apt-get install ca-certificates | |
COPY --from=build /repo/test/OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/otel-collector-config/otel-collector.crt /usr/local/share/ca-certificates/ | |
RUN update-ca-certificates --verbose |
I had actually tried this first:
ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, policyErrors) => true;
For some reason this did not work... I've used this kind of thing in test applications before, but for some reason the callback was not getting invoked by the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ServicePointManager.ServerCertificateValidationCallback
doesn't work for the Google library or .NET or both? I'm not too surprised if it doesn't work in the Google library. .NET would be more of a surprise 😄
…emetry-dotnet into alanwest/otlp-allow-tls
.../OpenTelemetry.Exporter.OpenTelemetryProtocol.Tests/otel-collector-config/otel-collector.crt
Outdated
Show resolved
Hide resolved
Related to this area in spec: open-telemetry/opentelemetry-specification#1426 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@cijothomas I think this is good to go. I had one comment that could be followed up on about expanding this test to test both http and https. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Based on the conversation in #1778, I think it may be safe to re-enable TLS support for the simple case.
We use two gRPC libraries
1. Google gRPC library (used for apps prior to .NET Core 3.0)
If the scheme is https then the channel is constructed with
new SslCredentials()
.Documentation of SslCredentials states:
2. gRPC .NET (used for apps supporting netstandard2.1)
gRPC channel can be constructed from a Uri with an https scheme, so I think TLS will just work.
I think this is enough to get us basic support for TLS over http. The spec still has some in-flight changes to configuration options that may allow us to provide a more flexible solution in the future. Also, support for unix sockets could come later too.
I'm going to try to expand the integration tests we have for the OtlpExporter to vet out these changes to ensure TLS works as I expect.