-
Notifications
You must be signed in to change notification settings - Fork 411
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
Enable TLS between the collector and application pods #2997
Comments
We're actually currently working on this for the target allocator and collector connections (pr here). I think once that lands, it would be simpler to evaluate the lift to enable it for the instrumentations and collectors. Definitely a great idea, and something that would be valuable for users. Do you expect this would only work automatically if the operator's user has cert-manager installed? Would you like a solution where a user can supply a certificate to be used for that connection? |
Yes, I think the optimal solution is for a way to automatically refresh certificates for clusters using cert-manager. Otherwise customers would have to supply a certificate and manage the rotation themselves. |
And to confirm, you wouldn't want a way for a user to supply and manage the rotation themselves (at least not initially)? |
Yes, I think for clusters with cert manager, we can be opinionated to have the certificates rotate automatically -- maybe have a default expiry on the cert. |
sounds good! Any chance you would be able to / want to work on this? If not, I can ask around the SIG / slack and see if anyone has some cycles. |
Thanks for the help @jaronoff97. I would be open to working on this, however I am not sure how the certificate refresh would work with the auto instrumentation SDKs without restarting application pods (or maybe that's the only approach?) It would be great to see if anyone with more knowledge can work on this. |
I think we could to set the rotation time to be 1/2 the lifetime of a cert (this is what istio did). From there we could probably give feedback to users via webhooks about workloads that need rotation. We've had a few conversations about restarting application pods and I think we've decided that for now we won't be in the business of doing that (it can be a concern for some users). @pavolloffay @swiatekm-sumo what do you both think? |
Component(s)
auto-instrumentation
Is your feature request related to a problem? Please describe.
The OpenTelemetry Collector's otlpreceiver supports a TLS configuration which can be configured like so:
The OpenTelemetry instrumentation libraries have certificates which can be configurable via environment variables:
Can we have a feature in the opentelemetry-operator to enable TLS between the collector and my application pods using the above information?
Documentation for otel specification, java, python
Describe the solution you'd like
It would be great if I could install the operator via helm chart and provide the certificate resource and then the operator could inject the TLS configuration in the otlp receiver of the collector, and inject the required environment variables in my application pods.
If my certificate gets refreshed or rotated in the resource, then the operator would be able to update the certificates used for TLS on my cluster.
Describe alternatives you've considered
Currently this can be enabled manually by setting the collector config to use a volume mount with the certificate, and then setting the environment variable in my application pod pointing to the same volume mount. Was looking to see if there is an easier way of enabling this without modifying my application spec.
Additional context
Not sure what the right approach here would be. There might be some complexities with refreshing the certificate and potentially having to restart application pods? Open to ideas and suggestions.
The text was updated successfully, but these errors were encountered: