Skip to content
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

Configuring OpenTelemetry via tyk-stack Helm chart exposes Authorization token #363

Open
sym-stiller opened this issue Nov 27, 2024 · 0 comments · May be fixed by #375
Open

Configuring OpenTelemetry via tyk-stack Helm chart exposes Authorization token #363

sym-stiller opened this issue Nov 27, 2024 · 0 comments · May be fixed by #375

Comments

@sym-stiller
Copy link

Hi!

I'm currently trying to set up the OpenTelemetry integration with Elasticsearch (according to this tutorial). We're using the tyk-stack Helm chart, and a managed Elasticsearch service.

Our OTel Collector requires clients to send an Authorization header with a secret Bearer token. The only way to configure this in the tyk-stack Helm chart is to supply the header via the tyk-gateway.gateway.opentelemetry.headers value:

tyk-gateway:
  gateway:
    opentelemetry:
      headers:
        Authorization: "Bearer supersecrettoken"

Our issue with this approach is that the Bearer token is now visible to anyone that has either access to our values.yaml, or to anyone who has sufficient permissions to inspect the deployment via K8s API. It would be much better if we could supply the Bearer token via a K8s secret. This way, the Tyk gateway deployment could source the token from that secret, which could look something like this:

spec:
  containers:
    - name: gateway
       env:
          - name: TYK_GW_OPENTELEMETRY_HEADERS
            valueFrom:
              secretKeyRef:
                name: otel-auth-secret
                key: Authorization

I'll prepare a pull request with a possible solution to discuss.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant