How to Securely Configure the OpenTelemetry Collector

Telemetry is critical to understanding and maintaining applications. Equally important is collecting and transporting telemetry securely as it flows through your system — from services to the observability backend.

The OpenTelemetry (OTEL) Collector (opens in a new tab) is a vendor-agnostic implementation for receiving, processing, and exporting telemetry data such as traces, logs, and metrics. It provides a structured pipeline that introduces an abstraction layer between applications and observability backends, enabling centralized data management.

Unlike agent-per-service models, the Collector offers a single point of control, reducing the surface area for security risks. Securing and properly configuring this layer is key to maintaining telemetry integrity.

In this guide, we’ll walk through configuring the OpenTelemetry Collector with a focus on security, helping you set up your telemetry pipeline with best practices in mind.

Understanding the Building Blocks of a Secure Collector

Collector Pipeline and Components

It is important to understand the architecture of the Collector to understand where vulnerabilities can arise. The Collector consists of three components that form the foundation for how data is received, processed, and exported.

• Receivers collect telemetry from data sources (opens in a new tab) and serve as a required entry point for Collectors. They translate incoming data from instrumented (opens in a new tab) applications to an OTEL format, preparing the data for any subsequent steps.
• Processors apply **transformations to ingested telemetry. Each defined processor may include a set of operations (i.e., filtering, renaming, redaction, batching) to transform data before export.
• Exporters send processed **telemetry to external observability backends or pipelines (opens in a new tab) that have native support for OpenTelemetry Protocol (OTLP) (opens in a new tab). They serve as the final stage in the Collector pipeline.

In addition to the core pipeline, the Connector also supports optional components that extend its functionality:

• Connectors join receiver and exporter logic, facilitating data exchange between pipelines. They enable capabilities like transforming data types in-transit, summarizing consumed data, replicating telemetry, or even routing to multiple destinations.
• Extensions provide auxiliary functionality to the Collector. Some features include health monitoring, service discovery, and authentication.

Next, let’s look at a basic, intentionally insecure, OTEL Collector configuration. This will serve as our starting point to identify where to apply security settings:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317  # OTLP over gRPC
      http:
        endpoint: 0.0.0.0:4318  # OTLP over HTTP
 
processors:
  batch:  # Batches telemetry for more efficient export
 
exporters:
  otlp:
    endpoint: otelcol:4317  # Sends data to a backend OTLP receiver (observability backend/platform)
 
extensions:
  health_check:  # Enables a health check endpoint
  pprof:         # Enables performance profiling
  zpages:        # Adds zPages for live debugging
 
service: # Define flow of components
  extensions: [health_check, pprof, zpages] # Enable extensions on pipelines below
  pipelines:
    traces:
      receivers: [otlp]   # Pulls in OTLP receiver
      processors: [batch] # Applies batch processing
      exporters: [otlp]   # Sends data to OTLP exporter
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Best Practices for Secure Configuration

The OTEL framework and community provide pre-built Collectors (opens in a new tab) for various use cases and each undergo transparent stability assessments (opens in a new tab). While the OpenTelemetry Collector operates securely out of the box, its security posture ultimately depends on how it’s configured.

Minimize Configuration Components

Limiting your Collector to only the core components you need is critical to minimize the attack surface. More components increases the potential for misconfiguration, unnecessary exposure, or unpatched vulnerabilities — especially with early-stage components.

For more control over the components used, use the OpenTelemetry Collector Builder (ocb) (opens in a new tab) to create a custom distribution and binary. This allows you to specify only the receivers, exporters, and extensions you need.

Secure Every Connection Point

Data movement is a point of exposure — every pathway and connection point is a potential attack surface. Receivers and exporters must communicate over encrypted, authenticated channels, and ports should never be exposed to untrusted endpoints.

Encryption of your telemetry data ensures your data is secure while in transit between your services, Collector, and observability backend. This will help prevent malicious interception or tampering. Use TLS certificates or mutual TLS (mTLS) — where both client and server validate each other — to secure these communication channels in production environments.

It is recommended to obtain production-ready certificates using your organization’s standard certificate provisioning process (i.e., internal PKI, AWS ACM, or Azure KeyVault).

Authentication is essential to prevent unauthorized access and ensure only trusted systems exchange telemetry. For receivers that expose a port (such as HTTPS or gRPC), they can be secured using the Collector’s default authentication mechanism (opens in a new tab). Similarly, exporters can use API tokens or client certificates and attach authentication data to outgoing requests.

Store Configurations Securely

Collector configurations often contain sensitive information such as authentication credentials, private keys, or backend endpoints. Typically, developers use environment variables (opens in a new tab) to inject values into configuration files. To safeguard these variables, it’s best to use a secrets management service like Infisical.com (opens in a new tab) that is enterprise-friendly with approval workflows.

Implementing Safe Permissions for OpenTelemetry Collector

Apply the principle of least privilege to minimize risk of unauthorized access and unintended exposure of sensitive data. Components should only have the access they need to complete their task. Note the following:

• Avoid running the Collector as a root user. Only provide minimal permissions to access to configuration files, reading telemetry data, and writing to outputs. Avoid any elevation of privileges outside of the core component needs.
• Be cautious with observers and extensions. Some of the features provided by extensions (e.g., host observers or system diagnostics) may require access to system processes, networks, or runtimes. Only enable these when necessary, and scope their permissions at the OS-level or use container sandboxing mechanisms.

Protecting Against Common Security Threats

Prevent Denial-of-Service (DoS) Attacks

The Collector should be protected from public or untrusted network exposure. Misconfigured endpoints can be vulnerable to overload and abuse. Follow these precautions to reduce the risk of a DoS attack:

• Bind to specific network interfaces, such as trusted IP addresses or localhost when appropriate. Avoid using 0.0.0.0, which binds the Collector to all interfaces and can unintentionally expose it to untrusted networks.
• Be aware of nonstandard networking setups. Containerized environments such as Kubernetes (opens in a new tab) or Docker (opens in a new tab) may need special configurations to avoid unintentionally exposing ports or defaulting to insecure network bindings. Verify the environments handling of service exposure, port mappings, and network interfaces and configure accordingly.

Scrub Sensitive Telemetry

Think of the processor as your telemetry firewall — the last point of control before data leaves your network. This is where you can apply transformations to remove any PII, credentials, tokens, or sensitive data before exporting it to an observability backend.

Example: Secure OpenTelemetry Collector YAML Configuration

Let’s walk through a full example of a Collector configuration that incorporates the security suggestions covered in this guide. This includes encryption, authentication, restricted network exposure, safe permissions, and data redaction.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317  # bind only to localhost
        tls_settings: # communication encryption
          cert_file: /etc/otel/certs/server.crt
          key_file: /etc/otel/certs/server.key
          client_ca_file: /etc/otel/certs/ca.crt  # enables mTLS
          client_auth: require_and_verify_client_cert
      http:
        endpoint: 127.0.0.1:4318  # limited to localhost
        tls_settings:
          cert_file: /etc/otel/certs/server.crt
          key_file: /etc/otel/certs/server.key
 
processors:
  batch:
  attributes:
    actions:
      - key: http.request.header.authorization
        action: delete  # redact sensitive headers
      - key: user.email
        action: delete  # remove user email PII
 
exporters:
  otlp:
    endpoint: your-backend.example.com:4317
    tls: # encrypt outgoing data
      ca_file: /etc/otel/certs/backend-ca.crt
      cert_file: /etc/otel/certs/client.crt
      key_file: /etc/otel/certs/client.key
 
extensions:
  # avoid including high-permission extensions
  h_check:
  basicauth/client: # enable authentication
	  # store credentials as environment variables
    client_auth:
      username: "${OTEL_USERNAME}"
      password: "${OTEL_PASSWORD}"  
      
  extensions: [health_check, basicauth/client]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [attributes, batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
 

Conclusion: Continuous Monitoring and Audit for OpenTelemetry Security

Securing your OpenTelemetry Collector is an iterative process. Infrastructure evolves, data drifts occur, and new Collector versions introduce both capabilities and potential risks. Continuous monitoring and regular auditing of your configuration and components is essential to remain aligned with security policies and observability goals.

However, OpenTelemetry is not an observability backend — it is a framework for collecting and exporting your telemetry data. Integrating with an open-source observability platform like HyperDX (opens in a new tab) gives developers end-to-end visibility, correlation across logs, traces, and metrics, and the ability to detect misconfiguration and security issues in real time.