-
Notifications
You must be signed in to change notification settings - Fork 769
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
Otlp grpc tls certificates #4731
Conversation
fcb7ec6
to
53e4c43
Compare
53e4c43
to
3e773a1
Compare
@@ -84,6 +88,21 @@ public OtlpExporterOptions() | |||
this.TimeoutMilliseconds = timeout; | |||
} | |||
|
|||
if (configuration.TryGetStringValue(ClientCertificateFileEnvVarName, out var clientCertificateFile)) |
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.
It might make sense to add a TryGetFilePath
method. Similar to the TryGetUriValue
it could validate that the string is a file path for an existing file and log a message if it isn't.
opentelemetry-dotnet/src/Shared/Options/ConfigurationExtensions.cs
Lines 69 to 73 in 8f38400
if (!Uri.TryCreate(stringValue, UriKind.Absolute, out value)) | |
{ | |
LogInvalidEnvironmentVariable?.Invoke(key, stringValue!); | |
return false; | |
} |
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.
After trying this I think a TryGetFilePath()
method doesn't make much sense here. The TryGet...
methods simply check if the value is syntactically valid and not whether the resource actually exists (e.g. URI).
If the certificate file with specified path doesn't exist then TryGetFilePath()
would return false
and the option would be set to null
and treated as if no option has been set by the developer.
I think from a developer PoV, if the file doesn't exist I'd prefer to be notified with a FileNotFoundException
.
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.
Syntactic validation is what I had in mind - using something like Path.GetInvalidPathChars
or something. Though file paths may be tricky to validate syntactically in a meaningful/helpful way, so I'm fine with not doing anything more in this PR.
@@ -22,6 +22,12 @@ | |||
<PackageReference Include="Microsoft.Extensions.Http" /> | |||
</ItemGroup> | |||
|
|||
<ItemGroup> | |||
<Content Include="Certificates\**"> |
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.
In #4732 I tried to avoid adding test certs/keys to the repo and generated them on the fly. See: https://github.com/open-telemetry/opentelemetry-dotnet/pull/4732/files#diff-5b358d0b47462dc9c3919270476736612be64b9db3362961d5df3d8b6defc257R4-R6.
The tests you have in this PR aren't run in docker of course, but I'm wondering if we can do something similar to avoid adding certs and keys.
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.
One way to do it I guess would be to add an MSBuild Task to run the scripts to generate the certs (sh on Linux, Powershell on Windows).
Gonna take a crack at this.
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.
Hey @dhhoang, apologies, I haven't had a chance yet to circle back and give this PR another pass. I will look at it more closely again tomorrow.
Though, quick thought about generating these certs, another idea may be to perform these tests using the integration test framework I landed in #4732. It's a minor bummer to have the tests you have so far depend on docker-compose to run them, but I figure you'll want to expand the integration tests anyways to test mTLS end to end.
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.
It just occurred to me a readme for how to run the integration test locally might be useful. See #4741.
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.
Giving this a try right now, I'll mark the PR as draft in the mean time.
💯 yes this would be great! Once we can get #4732 landed, then I think you could expand on it and test mTLS. You could probably add an additional OTLP receiver with the necessary mTLS config. See: https://github.com/open-telemetry/opentelemetry-dotnet/pull/4732/files#diff-836987be2117c46a9d22eb1a86fe30cee3eee98299b46abceb7fcc6e9e84e1c9R14 |
…dd unit tests to verify exceptions
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #4731 +/- ##
==========================================
- Coverage 82.13% 81.97% -0.16%
==========================================
Files 313 313
Lines 12783 12773 -10
==========================================
- Hits 10499 10471 -28
- Misses 2284 2302 +18
|
Finally got the time to work on this! I've finished the test cases:
Marking this PR as ready for review. |
handler.ServerCertificateCustomValidationCallback = (message, serverCert, chain, policyErrs) => | ||
{ | ||
chain.ChainPolicy.TrustMode = X509ChainTrustMode.CustomRootTrust; | ||
chain.ChainPolicy.CustomTrustStore.Add(trustedCA); | ||
var buildResult = chain.Build(serverCert); | ||
return buildResult; | ||
}; |
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.
I'm not an expert on these things, so still need to do some of my own research to understand if this is sufficient.
One thing that leaves me a bit unsure here is that policyErrs
is ignored. My understanding is the "out-of-the-box" validations would be reflected in policyErrs
(e.g., is the cert signed by a trusted CA, is the cert expired, etc). I suspect we want the custom validation here to be in addition to the out-of-the-box validations.
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.
You're correct that policyErrs
would contain the error that the "default" validation method returns. The default validator would trust the certificates in the root trust store (aka certificates "installed" on the machine).
If user is manually trusting a certificate, it means the certificate might not be in the machine root store and we need to at least ignore that error.
The other validation criteria (e.g. expiration, revocation) is encoded in the X509Chain
parameter. In this implementation I keep them as default settings (other than TrustMode
of course). This means that other failure criteria would still work (e.g. the trusted cert still fails if it's expired).
Hey @dhhoang, thanks for your patience. I've had limited time to give this PR a thorough review, so I appreciate you bearing with me 😄 - I am looking forward to getting this support landed! Since this is your first PR to this repo, would you mind landing it in a few iterations? If you land a small PR first, then your "first-time contributor" status will go away and then on subsequent PRs the CI will just run automatically. Here's a suggestion for breaking this PR up into multiple PRs:
|
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day. |
This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or Pushing will instruct the bot to automatically remove the label. This bot runs once per day. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Fixes #2009
Design discussion issue #2009
Changes
Implement the configurations according to specs:
OTEL_EXPORTER_OTLP_CERTIFICATE
OTEL_EXPORTER_OTLP_CLIENT_KEY
OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE
Notes
Some known issues:
HTTP/Protobuf
protocol, the options only work forNET6_0_OR_GREATER
targets. Older .NET lacks the required APIs to load PEM certificates. Implementing this would require essentially porting those APIs back from .NET 6. Given thatHttpClientFactory
can be used forHTTP/Protobuf
I don't think it's worth the effort.GRPC flow
. I'd love to have some end-to-end tests where the test case can communicate with a GRPC server to verify the mTLS functionalities. That's the only way to know whether the code works, because some of the options here passed to native C bindings (for GRPC in older .NET) and hence not possible to do any meaningful unit test. I'd like to hear recommendations on how these kinds of test could be done.Merge requirement checklist
CHANGELOG.md
files updated for non-trivial changes