Jaeger v2 via OpenTelemetry operator - provide elasticsearch username and password via Kubernetes secret? #6778
-
|
In the old operator syntax, we could do (simplified): apiVersion: jaegertracing.io/v1
kind: Jaeger
spec:
storage:
elasticsearch:
name: elasticsearch
nodeCount: 3
redundancyPolicy: SingleRedundancy
options:
es.server-urls: 'https://elasticjaegersearch-es-http.elastic-system.svc:9200'
secretName: elasticsearch-jaeger # <-- this
type: elasticsearchWhich would allow us to provide the ES_USERNAME and ES_PASSWORD required to connect to elasticsearch via a secret (in this case, called I cannot find out whether or not the new v2 via OpenTelemetry operator supports anything similar. We have (from: https://docs.google.com/document/d/1rabu8zvjoZeHx-HNqvK5kjsujMEBC7DkR2MYeOvB6HI/edit?tab=t.0): auth:
basic:
password:and auth:
basic:
username: and auth:
basic:
password_file:But the format of the password file is unknown/undocumented, and there is no comment on whether the old environment variables which would be provided by a secret (e.g., ES_USERNAME and ES_PASSWORD) are still supported or how to get them into the container. Thoughts are appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 13 replies
-
|
Yes, the new Jaeger v2 via OpenTelemetry operator does support providing Elasticsearch username and password via Kubernetes secrets, similar to the old operator syntax. You can configure this by specifying a secret that contains the environment variables apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: simple-prod
spec:
strategy: production
storage:
type: elasticsearch
options:
es:
server-urls: https://quickstart-es-http.default.svc:9200
index-prefix: my-prefix
tls:
ca: /es/certificates/ca.crt
secretName: jaeger-secret
volumeMounts:
- name: certificates
mountPath: /es/certificates/
readOnly: true
volumes:
- name: certificates
secret:
secretName: quickstart-es-http-certs-publicYou can create the secret using the following command: kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=password --from-literal=ES_USERNAME=elasticThis setup allows you to continue using Kubernetes secrets to manage your Elasticsearch credentials [1]. To continue talking to Dosu, mention @dosu. Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other |
Beta Was this translation helpful? Give feedback.
-
|
@dosu that syntax does not show the opentelemetry operator syntax, but the old syntax. |
Beta Was this translation helpful? Give feedback.
-
|
To provide Elasticsearch username and password via Kubernetes secrets using the OpenTelemetry operator syntax for Jaeger v2, you can define a Kubernetes secret and reference it in your Jaeger custom resource. Here's how you can do it:
This configuration will make the Elasticsearch credentials available as environment variables in the Jaeger components (Collector/Query/All-In-One) [1]. To continue talking to Dosu, mention @dosu. Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other |
Beta Was this translation helpful? Give feedback.
-
|
I do not believe the v2 operator supports orchestration for storage (since the operator is really just the official OTEL operator that does not deal with storage). You need to
|
Beta Was this translation helpful? Give feedback.
-
|
@yurishkuro thanks for the reply. My question isn't about deploying storage (e.g., elasticsearch) with the v2 operator, it's about how to provide the credentials for storage (deployed elsewhere) to the operator. As mentioned, in the previous v1 operator you could provide That functionality is either undocumented in v2 or doesn't exist the same way. |
Beta Was this translation helpful? Give feedback.
-
|
Because operator does not deal with storage you cannot pass storage params via spec. You need to create a custom OTEL collector config (example) and pass it as a whole. Within that config you can specify extensions:
jaeger_storage:
backends:
some_storage:
elasticsearch:
auth:
basic:
username: somevalue
password: somevalueIf you then want to customize those credential values via env vars, you can change the config accordingly |
Beta Was this translation helpful? Give feedback.
-
|
@yurishkuro I must be misunderstanding something. Given this v1 spec (copied from https://www.jaegertracing.io/docs/1.66/operator/#external-elasticsearch): apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
name: simple-prod
spec:
strategy: production
storage:
type: elasticsearch # <1>
options:
es:
server-urls: https://quickstart-es-http.default.svc:9200 # <2>
index-prefix: my-prefix
tls: # <3>
ca: /es/certificates/ca.crt
secretName: jaeger-secret # <4>
volumeMounts: # <5>
- name: certificates
mountPath: /es/certificates/
readOnly: true
volumes:
- name: certificates
secret:
secretName: quickstart-es-http-certs-publicI do not expect the Jaeger operator to deploy or manage any storage. The I am mostly interested in the functionality around point <4> lower down in the documentation:
The way I understand this, the line in the spec at I am just looking to validate that Jaeger v2 has the same functionality (mostly whether or not it reads the environment variables If your config: auth:
basic:
username: "${env:ES_USERNAME}"
password: "${env:ES_PASSWORD}"Accomplishes this, that's a bit odd, but functional (if arguably a step backwards from v1) and it would be great to see some documentation on that. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
the spec has no relation to Jaeger v2. That spec is for v1 operator, which does not support Jaeger v2. For Jaeger v2 you need to use OTEL operator as explained in the doc https://github.com/jaegertracing/jaeger-operator#jager-v2-operator |
Beta Was this translation helpful? Give feedback.
-
|
@yurishkuro I understand the difference between the v1 Jaeger and v2 OTEL operators and their specs; that is not the question I am asking. I am asking whether Jaeger v2 consumes the two environment variables Alternatively, I am looking for guidance on the file format required by the following v2 spec: auth:
basic:
password_file: # <- what is the needed format for this file? Is a text file with just the password inside sufficient? |
Beta Was this translation helpful? Give feedback.
-
|
Jaeger v2 itself does not read any environment variables, it only reads YAML config. But within that config you yourself can use environment variables as I showed above. The password file is just a plain text file with clear password. I would probably avoid using new-line terminator in that file as well, not sure if the code will strip it or not. |
Beta Was this translation helpful? Give feedback.
Because operator does not deal with storage you cannot pass storage params via spec. You need to create a custom OTEL collector config (example) and pass it as a whole. Within that config you can specify
auth:If you then want to customize those credential values via env vars, you can change the config accordingly