feat: secretKeyRef support in extraProcEnvVars

[ion-elgreco]

Description
Allows references secrets in the ext_proc env vars as a value: secretKeyRef {"name":"secret_name", "key": "secret_key"}

Complete example:

OTEL_EXPORTER_OTLP_HEADERS=secretKeyRef {"name":"secret_name", "key": "secret_key"}

This should also enable layering secrets with k8s, so you can configure you values.yaml this way for aigw, where secret_key is just the plain secret and then OTEL_EXPORTER_OTLP_HEADERS adds Bearer as prefix, while taking $SECRET_HEADER from the env var:

extProc:
  extraEnvVars:
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: http://phoenix-svc.phoenix.svc.cluster.local:6006
    - name: SECRET_HEADER
      value: "secretKeyRef {\"name\":\"secret_name\", \"key\": \"secret_key\"}"
    - name: OTEL_EXPORTER_OTLP_HEADERS
      value: "Bearer $SECRET_HEADER"

• closes docs: update with instructions on how to authenticate Phoenix (for genai traces) #1121

cc @codefromthecrypt, @mathetake

[mathetake]

Thanks, did you consider alternatives like

1. Introduce another flag dedicated for secretRef
2. Add support for valueFrom at extraEnvVars of helm level to match the Kubernetes API
3. Pass the secretRefs from the helm into the new dedicated flag for secretRef
4. Pass the secretRef as-is into the pod template

That way, we could avoid conflating everything in the comma separate stuff like the current one. Manual parsing like this seems an error-prone and looks clunky to be honest.

wdyt?

[codefromthecrypt]

ps thanks for working on this

[ion-elgreco]

Thanks, did you consider alternatives like

1. Introduce another flag dedicated for secretRef
2. Add support for valueFrom at extraEnvVars of helm level to match the Kubernetes API
3. Pass the secretRefs from the helm into the new dedicated flag for secretRef
4. Pass the secretRef as-is into the pod template

That way, we could avoid conflating everything in the comma separate stuff like the current one. Manual parsing like this seems an error-prone and looks clunky to be honest.

wdyt?

I didn't want to change to much beyond what I did now, since I didn't know how big of a change was acceptable.

Option 2 would definetely solve the error prone issue, because we would know how valueFrom gets converted into a string and decoded again.

The main issue is we have to go through this string structure, not sure if i'ts possible otherwise since I don't know the codebase well enough, but can definetly work another approach

[mathetake]

@ion-elgreco let me know if you have any intent to continue this PR or cool with closing this one since it's been a while since last activity

[ion-elgreco]

@mathetake yes, I would like to but have to find some time