OpenTelemetry Collector authentication and access control

A single Collector sits in two authentication relationships at once. On the inbound side, applications, agents or other Collectors authenticate to a receiver, typically the OTLP receiver on a gateway. On the outbound side, the same Collector authenticates to the backend or downstream Collector through an exporter. These are separate trust decisions with separate credentials, so an access design should map each direction on its own before any configuration is written. Confirm with your team which senders must reach the gateway, which backend endpoints the gateway must reach, and whether any sender is itself a Collector that will need the same treatment.

On the receiver side, an authenticator extension is attached to the receiver's transport settings so that every incoming connection is checked before data enters the pipeline. The OIDC authenticator is the case the topic centers on: the Collector trusts a configured identity provider and accepts only tokens that provider issued and that validate against its keys and expected audience. Senders hold their own credentials, usually a token or certificate issued by that identity provider, and the sender's configuration is where that credential lives. The Collector itself stores only the trust configuration: the issuer, the audience and how keys are obtained. Ask your identity team which token endpoint and issuer each sender group will use, and whether those tokens carry the claims you intend to authorize against.

On the exporter side, the direction reverses. The oauth2client extension obtains a token from a configured token endpoint using client credentials, then attaches it to outgoing requests to the backend. In this case the Collector holds a client identifier and secret, or the equivalent material, and that secret is the most sensitive credential in the design because compromise lets anyone present the gateway's identity to the backend. Store it outside the Collector configuration file, restrict who can read the deployment, and plan a rotation procedure before go-live. Confirm with the backend owner which token endpoint, scopes and audience the backend expects, since a mismatch will fail at the backend even when the Collector is configured correctly.

A rejected request should surface in two places that operators can see. On the inbound path, the sender receives an authentication failure from the receiver and the Collector should record it, so a misconfigured or expired sender is visible without needing a packet capture. On the outbound path, a failed token fetch or a rejected export appears in Collector logs and in the exporter's failure telemetry, which may be retried and eventually dropped. Decide in advance who owns each signal, which alerts fire on repeated authentication failures, and how a credential expiry differs from a network fault in the runbook. Test both failure paths deliberately in a non-production environment, because the default behavior is easy to assume and hard to notice in production traffic.

Finally, TLS is the layer that protects both directions in transit, and it should be planned with the authenticator rather than after it. Authentication tells the Collector who is calling, while TLS protects the token and the data from interception and confirms the peer's identity. Verify certificate chains for the receiver and each exporter endpoint, and confirm how certificate rotation will be handled for each. The OpenTelemetry Collector security guidance recommends encrypting and authenticating the Collector's configuration and traffic, so treat these controls as a set in your access design and review them against the component documentation for your Collector version.

Testing Collector authentication means proving two things: that authorized senders and exporters get through, and that every failure mode rejects traffic without leaking credentials or silently losing data. Run both groups of tests against a staging Collector that uses the same authenticator extensions, receiver settings and TLS configuration as production, because a test against a relaxed copy proves little. Record the expected outcome for each case before you run it, so a result can be judged as pass or fail rather than explained after the fact. The positive tests start with an authorized sender. Use a client that holds a valid token or certificate issued by the identity provider configured for the receiver, send traces, metrics and logs through the OIDC or other authenticator extension, and confirm the data reaches the pipeline and the exporter. Then test token refresh: let a short-lived token approach expiry, allow the client to obtain a new one, and confirm telemetry keeps flowing without a restart or manual intervention. On the egress side, use the oauth2client extension on the exporter, confirm the Collector attaches credentials to outgoing requests, and verify that the backend accepts them and stores the test records. The negative tests should cover each credential path. Send a request with no token and confirm the receiver refuses it. Present an expired client certificate and confirm the TLS handshake or authenticator rejects it. Issue a token for a different audience and confirm it is refused even though its signature is valid, since audience checks are a common gap. Finally, point the receiver at an identity provider that you have made unreachable and observe what happens to inbound requests and to the Collector's own startup and token fetches. Document whether senders receive a clear error, whether the Collector fails closed, and how long recovery takes once the provider returns. Confirm the exact behavior of each authenticator in the version you run, because the component stability levels are documented per component and can change between releases. Rejected requests should be visible in Collector logs and internal telemetry, so check both after every negative test. Look for authentication failure entries from the receiver, confirm they name the failing check without printing the token, certificate private key or client secret, and make sure your log pipeline does not forward those lines to a backend that is less protected than the Collector. Confirm the Collector's own telemetry reports refused and failed exports, and that the sending side shows an error rather than a success. Then verify the failure path for data: when an exporter cannot authenticate to its backend, confirm whether data is dropped or held in the sending queue, how large that queue is configured to grow, and what happens to queued data once credentials are restored. A good test record lists each case, the expected result, the observed result, the log and metric evidence, and any credential exposure found. Ask your implementation partner or internal team to keep these records as evidence for your change process and for your compliance team, and rerun the full set after every Collector upgrade, identity provider change or certificate rotation. Note that DeployOpen prepares test plans and evidence but does not issue audit reports or certifications; an independent assessor decides whether your controls meet a given standard.

Authentication on a Collector is only as good as the operational routine around it. The first thing to set up after go-live is monitoring for rejected requests and authentication errors on each receiver that has an authenticator extension attached, such as an OIDC authenticator on an OTLP receiver. Rejections from a sender that should be authorized usually point to an expired token, a changed issuer URL, a clock skew problem or a certificate the sender no longer trusts. Rejections from unknown callers are the signal you actually want to act on. Ask your team to confirm which log lines and metrics the chosen Collector version emits for authenticator failures, since the exact names and availability vary by component and release, and to route them to the same alerting path used for the rest of the pipeline.

Credentials need a rotation plan before anyone needs one in a hurry. Two kinds of material matter here. Inbound, the receivers trust certificates or identity provider keys that the authenticator validates against, so a rotated CA or signing key has to be staged so both old and new material are accepted during the switch. Outbound, the oauth2client extension holds client credentials that the Collector uses to call exporters, so the client secret must be rotated in the identity provider and in the Collector configuration or secret store in a single controlled change. Confirm with your identity team how long old secrets remain valid, who holds the rotation runbook, and whether the Collector can reload credentials without a restart in the version you deploy.

Collector releases arrive often, and the release history itself is a planning input. Collector v0.161.0 shipped on September 16, 2026, v0.162.0 on September 29, and v0.163.0 on October 16, 2026. Each release is published with signed artifacts, SHA256 checksums and SBOM files, which your change process should verify before deployment. Because core components carry mixed stability levels, an authenticator that was stable in one release can change configuration or behavior in a later one. Treat every Collector upgrade as a trigger to re-run your authentication tests: send a valid request, an expired token, a wrong audience, and a request with no credentials to each authenticated receiver, and confirm the outcome matches your design. Check the status page and each component README before upgrading.

The sender inventory is the document that makes all of the above manageable. For every application, agent, gateway and collector that sends telemetry, record the receiver it targets, the authentication method, the identity or certificate it presents, its owning team, and the data it is permitted to send. Record the trust relationships too: which identity provider issuers, certificate authorities and audiences each receiver accepts, and which backends each exporter authenticates to. Keep the inventory with the configuration in version control, and review it at each release and at each credential rotation. An unlisted sender that appears in the logs is then an investigation, not a guess. Ask your provider to deliver this inventory and the runbooks as part of the handover, and agree in the written scope who maintains them afterward.

Start with the official Collector configuration documentation before you write any authenticator block. The configuration reference explains how extensions are declared and then referenced from receivers and exporters, which is the mechanism behind every control in this topic. Read it alongside the authenticator extensions named in your design, such as the OIDC authenticator for incoming connections and the oauth2client extension for outgoing exporter requests. Confirm the current component README for each extension, because component stability levels differ and the README records the status of each one. Note the page and the version you reviewed, so your design record can be traced back to a specific documented state.

Next, read the OpenTelemetry Collector security best practices page as a checklist against your configuration. It covers storing Collector configuration securely, using encryption and authentication, building the Collector with only the components you need through the Collector Builder, and using the redaction processor for sensitive attributes. For this topic, the authentication guidance is the part that matters most: confirm that every receiver that accepts telemetry from outside the host has an authenticator attached, and that TLS is configured on the same endpoints. The same page notes that since Collector v0.110.0, server components bind to localhost by default rather than 0.0.0.0. If you expose a receiver on a network interface, you are changing a default, so record that change and the reason for it.

Use the Collector releases page to pin the version your access controls were tested against. The releases page lists each Collector release, and the most recent entries at the time of this writing were v0.163.0, released on October 16, 2026, v0.162.0 on September 29, 2026 and v0.161.0 on September 16, 2026. Confirm which release your target environment will run, and check its notes for changes to authenticator extensions, TLS settings or configuration keys before you upgrade. Release artifacts include signed binaries, SHA256 checksums and SBOM files. Verify the checksum and signature of the exact artifact you deploy, and keep the SBOM with your change records so your security team can match installed components to known advisories.

Treat the official pages as the baseline and record any gaps between them and your environment. Where the documentation is silent or a component is at an early stability level, write down the decision you made and who approved it, rather than assuming the behavior. Ask your implementation partner to tie each access control in the design to a specific documented setting and a release tested against it. Re-check these references at each upgrade, since the Collector ships frequently and the configuration surface for authentication can change between releases.