Securing OpenTelemetry in Legacy Systems: Best Practices

In today's world, observability is critical, especially in legacy environments where direct security measures may not be feasible. Applying OpenTelemetry security practices allows you to create a robust telemetry pipeline that acts as a control point, ensuring that data flows are secure and trustworthy. This is vital for maintaining operational integrity and compliance in complex systems.

The OpenTelemetry Collector operates outside the legacy system boundary, running on a separate host, VM, or container. This separation is crucial as it allows you to constrain ingestion points and classify data by source trust level. By isolating bridging components and minimizing exposed components, you can enforce a Zero Trust approach, where access is explicitly controlled rather than assumed safe based on network location. For example, you can use processors to hash user IDs and redact sensitive information, ensuring that only necessary data is exposed. Here’s a snippet that shows how to hash user IDs:

1transform/hash_user:
2    trace_statements:
3      - context:
4          span:
5        statements:
6          - set(attributes["user.hash"], SHA256(attributes["user.id"]))
7          - delete_key(attributes, "user.id")

In production, the key is to maintain a balance between observability and security. You need to be aware of the potential pitfalls, such as misconfigurations that could expose sensitive data. The versioning of OpenTelemetry is also important; staying updated ensures you benefit from the latest security features and fixes. Implementing strict redaction policies can further safeguard your telemetry data:

1redaction/strict:
2    allow_all_keys: false
3    allowed_keys:
4      - id
5      - name
6      - status