strimzi / strimzi-kafka-operator

Apache Kafka® running on Kubernetes
https://strimzi.io/
Apache License 2.0
4.76k stars 1.27k forks source link

Support for TLS on the OpenTelemetry OTLP Exporter #9170

Open ppatierno opened 11 months ago

ppatierno commented 11 months ago

When using the OpenTelemetry support for tracing, the default exporter is the OTLP one. It is automatically configured by the operator when the tracing type is set to opentelemetry. The exporter is configured via some OTEL_ prefixed env vars which are used by the OpenTelemetry SDK auto-configure extension in order to configure the exporter accordingly. If the tracing backend (i.e the Jaeger backend) is configured with TLS enabled on the OTLP endpoint, the way to configure the trusted certificate for the OpenTelemetry OTLP exporter is by using the OTEL_EXPORTER_OTLP_CERTIFICATE. An example configuration would be something like this:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  template:
    connectContainer:
      env:
        - name: OTEL_SERVICE_NAME
          value: my-otel-service
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://jaeger-all-in-one-inmemory-collector-headless.openshift-distributed-tracing.svc.cluster.local:4317"
        - name: OTEL_EXPORTER_OTLP_CERTIFICATE
          value: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"  
  tracing:
    type: opentelemetry

The above example works out of box when using OpenShift distributed tracing suite which deploys a Jaeger backend with TLS enabled by using the service-ca.crt mounted automatically on all pods.

As defined by the documentation, this env var contains:

The path to the file containing trusted certificates to use when verifying an OTLP trace, metric, or log server's TLS credentials. The file should contain one or more X.509 certificates in PEM format. By default the host platform's trusted root certificates are used.

The problem we have right now is about providing a way to mount "random" Secret on the pod where the application (i.e. Kafka Connect) is running. The Secret would host the certificate that should be set in the env var.

scholzj commented 11 months ago

Triaged on community call on 5.10.2023: Would be useful, but should have a proposal to clarify how the API would look like.

scholzj commented 1 day ago

@ppatierno We now have the ability to mount Secrets into any container. So can we move forward with this? Is this just a question of documentation now? Should we re-triage it?