The OpenTelemetry Collector sits between your applications and your storage, which makes it a good place to remove sensitive values and drop unneeded telemetry. Its redaction and filter processors do this centrally, and a few configuration habits keep the collector itself from becoming a weak point.
Why the pipeline is the right place
Fixing every application to stop logging a field takes weeks and never finishes. A pipeline stage applies the rule to everything passing through, including third party libraries. It is a safety net, not a substitute for logging carefully. Our posts on what never to log and personal data in logs cover the source side.
The processors that matter for security
The OpenTelemetry security documentation on collector configuration describes these.
Redaction processor. Deletes attributes that are not on an allowed list and masks values that match blocked patterns, for example credit card numbers. An allow list approach is stronger than a block list, because new fields are dropped by default rather than leaked by default.
Filter processor. Drops unneeded logs, metrics and spans. That protects the backend from volume and keeps low value data from being retained.
Batch and memory limiting. The documentation advises batching telemetry and setting memory limits to prevent out of memory errors and usage spikes.
Exact option names change between versions, so check the current documentation for your collector release before copying a configuration.
Hardening the collector
The same page lists practices that apply to the collector as a service:
- Protect the configuration. It may hold API tokens and TLS private keys. Keep it on an encrypted filesystem or in a secret store, and use environment variable expansion to keep secrets out of the file.
- Encrypt and authenticate. Set up certificates and enable built in authentication so components verify who connects.
- Bind narrowly. The documentation advises using specific interfaces, such as a pod IP or localhost, instead of
0.0.0.0. - Be careful with queue and buffer settings. Poor values can expose the collector to attacks.
- Build only what you need. Use the OpenTelemetry Collector Builder to include only required components and reduce attack surface.
- Do not run as root. Grant least privilege, including limited RBAC for observers.
- Tune exporters. Set queue sizes, timeouts and retries so outages do not pile up memory.
Order of operations in a pipeline
A sensible order is: receive, limit memory, filter out noise, redact, batch, export. Filtering before redaction saves work, and redacting before export guarantees nothing sensitive leaves.
Test the rules
Send a synthetic log record containing a fake card number and a fake token through a staging collector. Confirm the exported record has them masked. Keep the test in version control so a refactor cannot silently remove the rule.
What redaction cannot do
It cannot find secrets in free text it does not recognize, and a pattern can miss a variant. Treat it as one layer. Pair it with source side fixes and secret scanning.
Quick check
Should I redact at the collector or in the application?
Both. Fix known problems in the code, and keep the collector rules as a backstop for what you missed.
Does the filter processor risk dropping security events?
Yes, if a rule is too broad. Scope filters narrowly, and review dropped counts so you notice if a security source disappears.
Sources
Last reviewed: 19 October 2026.
