Try it free

Workload identity federation with the OTel Collector

  • Latest Dynatrace
  • How-to guide
  • 4-min read
  • Published Sep 07, 2026

The following configuration example shows how to configure a Collector instance to authenticate to Dynatrace using Workload Identity Federation (WIF) and a Kubernetes projected service-account token, without storing a long-lived API token. For background on how Dynatrace validates the token and maps it to a service user, see Workload identity federation.

Prerequisites

  • One of the following Collector distributions with the bearertokenauthextension:
    • The Dynatrace OTel Collector
    • A custom Builder version
  • The Dynatrace API endpoint URL to which the data should be exported

See Deploy the Dynatrace OTel Collector and Configure the OTel Collector on how to set up your Collector with the configuration below.

Kubernetes setup

To supply the Collector with a projected service account token, configure a projected volume in the Collector Deployment and mount it at the path referenced by the filename field in the extension config (in the example below, /var/run/secrets/dynatrace).

apiVersion: apps/v1
kind: Deployment
metadata:
name: dynatrace-otel-collector
spec:
replicas: 1
selector:
matchLabels:
app: dynatrace-otel-collector
template:
metadata:
labels:
app: dynatrace-otel-collector
spec:
serviceAccountName: dynatrace-otel-collector
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: collector
image: ghcr.io/dynatrace/dynatrace-otel-collector/dynatrace-otel-collector:v0.56.0
args: ["--config=/etc/otel/config.yaml"]
volumeMounts:
- name: config
mountPath: /etc/otel/config.yaml
subPath: config.yaml
- name: sa-token
mountPath: /var/run/secrets/dynatrace
readOnly: true
- name: tmp
mountPath: /tmp
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
volumes:
- name: config
configMap:
name: dynatrace-otel-collector-config
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: token
expirationSeconds: 3600
audience: "{your-audience}"
- name: tmp
emptyDir: {}

Two values must match across the configuration:

  • The audience in the projected volume must match the audience configured in the Dynatrace trust policy. See Workload identity federation.
  • The mountPath combined with path: token produces the token file path (/var/run/secrets/dynatrace/token), which must match the filename field in the bearertokenauth extension config.

The tmp volume is required when readOnlyRootFilesystem: true is set, as the Collector writes temporary files to /tmp at runtime.

Demo configuration

extensions:
health_check:
endpoint: 0.0.0.0:13133
bearertokenauth:
filename: /var/run/secrets/dynatrace/token
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
processors:
cumulative_to_delta:
max_staleness: 25h
exporters:
otlp_http:
endpoint: "${env:DT_ENDPOINT}"
auth:
authenticator: bearertokenauth
service:
extensions: [bearertokenauth, health_check]
pipelines:
traces:
receivers: [otlp]
processors: []
exporters: [otlp_http]
metrics:
receivers: [otlp]
processors: [cumulative_to_delta]
exporters: [otlp_http]
logs:
receivers: [otlp]
processors: []
exporters: [otlp_http]
Configuration validation

Validate your settings to avoid any configuration issues.

Components

For our configuration, we configure the following components.

Extensions

Under extensions, we configure two extensions:

  • bearertokenauth reads the projected service-account token file set by the filename field and attaches it as a Bearer credential on every outgoing request. The extension watches the file for changes and picks up renewals without a Collector restart - Kubernetes renews projected tokens automatically at roughly 80% of their configured TTL, so authentication continues without interruption. The scheme field controls the HTTP authorization scheme and defaults to Bearer.
  • health_check exposes an HTTP liveness endpoint at 0.0.0.0:13133. On Kubernetes, this endpoint is used for liveness and readiness probes.

Receivers

Under receivers, we specify the standard otlp receiver as active receiver component for our Collector instance and configure it to accept OTLP requests on gRPC and HTTP.

Processors

Under processors, we configure the cumulative_to_delta processor. This processor converts any cumulative metrics before export.

Dynatrace requires metrics in delta temporality. See Configure the OTel Collector for details.

Exporters

Under exporters, we specify the default otlp_http exporter and configure it with our Dynatrace API URL and a reference to the bearertokenauth extension.

For this purpose, we set the following environment variable and reference it in the configuration value for endpoint.

  • DT_ENDPOINT contains the base URL of the Dynatrace API endpoint (for example, https://{your-environment-id}.live.dynatrace.com/api/v2/otlp)

Service pipelines

Under service, we enable the bearertokenauth and health_check extensions and assemble three pipelines:

  • traces passes spans from the OTLP receiver to the OTLP exporter.
  • metrics converts cumulative metrics to delta before exporting to Dynatrace.
  • logs passes log records to the OTLP exporter.

Limits and limitations

Data is ingested using the OpenTelemetry protocol (OTLP) via the Dynatrace OTLP APIs and is subject to the API's limits and restrictions. For more information see:

  • OpenTelemetry metrics limitations
  • Dynatrace metrics mapping
  • Ingest OpenTelemetry logs

Related topics

  • Workload identity federation
  • Configure the OTel Collector
  • Deploy the Dynatrace OTel Collector
Related tags
Application Observability