Inconsistent Redaction of Numeric Attribute Values in the OpenTelemetry Collector

[andoniaf]

Component(s)

processor/redaction

What happened?

Description

When using the OpenTelemetry Collector's redaction processor with a configuration that includes regex-based redaction of specific attribute values, there is an issue where numeric values are not being redacted as expected.
Specifically, the redaction regex does not seem to match when the span attribute has only numeric values.

For instance, consider the following example where two spans are sent for processing:

./otel-cli span -s my-service --attrs app.dummy="4111111111111"
./otel-cli span -s my-service --attrs app.dummy="VISA 4111111111111"

In this case, the redaction processor only redacts the second span's attribute value, leaving the first one untouched.

Steps to Reproduce

1. Set up the OpenTelemetry Collector with the provided configuration for the redaction processor.

  redaction/cards:
    allow_all_keys: true
    blocked_values:
      - "4[0-9]{12}(?:[0-9]{3})?" ## Visa credit card number
    summary: debug

2. Generate spans with attributes containing numeric values, such as credit card numbers.

./otel-cli span -s my-service --attrs app.dummy="4111111111111"
./otel-cli span -s my-service --attrs app.dummy="VISA 4111111111111"

3. Observe that the redaction regex does not properly match and redact numeric attribute values.

otel-collector-otel-col-1  | 2023-08-31T08:40:36.480Z   info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 1}
otel-collector-otel-col-1  | 2023-08-31T08:40:36.481Z   info    ResourceSpans #0
otel-collector-otel-col-1  | Resource SchemaURL:
otel-collector-otel-col-1  | Resource attributes:
otel-collector-otel-col-1  |      -> service.name: Str(my-service)
otel-collector-otel-col-1  | ScopeSpans #0
otel-collector-otel-col-1  | ScopeSpans SchemaURL:
otel-collector-otel-col-1  | InstrumentationScope otel-cli/span
otel-collector-otel-col-1  | Span #0
otel-collector-otel-col-1  |     Trace ID       : ec0ce11b214f5d3524aac5914e517415
otel-collector-otel-col-1  |     Parent ID      :
otel-collector-otel-col-1  |     ID             : ff77f2dd838549da
otel-collector-otel-col-1  |     Name           : todo-generate-default-span-names
otel-collector-otel-col-1  |     Kind           : Client
otel-collector-otel-col-1  |     Start time     : 2023-08-31 08:40:36.456148 +0000 UTC
otel-collector-otel-col-1  |     End time       : 2023-08-31 08:40:36.456497 +0000 UTC
otel-collector-otel-col-1  |     Status code    : Unset
otel-collector-otel-col-1  |     Status message :
otel-collector-otel-col-1  | Attributes:
otel-collector-otel-col-1  |      -> app.dummy: Int(4111111111111)
otel-collector-otel-col-1  |    {"kind": "exporter", "data_type": "traces", "name": "logging"}
otel-collector-otel-col-1  | 2023-08-31T08:40:36.487Z   debug   [email protected]/otlp.go:118    Preparing to make HTTP request  {"kind": "exporter", "data_type": "traces", "name": "otlphttp/honeycomb", "url": "https://refinery:8080/v1/traces"}
otel-collector-otel-col-1  | 2023-08-31T08:40:42.477Z   info    TracesExporter  {"kind": "exporter", "data_type": "traces", "name": "logging", "resource spans": 1, "spans": 1}
otel-collector-otel-col-1  | 2023-08-31T08:40:42.478Z   info    ResourceSpans #0
otel-collector-otel-col-1  | Resource SchemaURL:
otel-collector-otel-col-1  | Resource attributes:
otel-collector-otel-col-1  |      -> service.name: Str(my-service)
otel-collector-otel-col-1  | ScopeSpans #0
otel-collector-otel-col-1  | ScopeSpans SchemaURL:
otel-collector-otel-col-1  | InstrumentationScope otel-cli/span
otel-collector-otel-col-1  | Span #0
otel-collector-otel-col-1  |     Trace ID       : 7d7a6785b7fbfda51ea8764d3131f165
otel-collector-otel-col-1  |     Parent ID      :
otel-collector-otel-col-1  |     ID             : 6216f0836ba7a780
otel-collector-otel-col-1  |     Name           : todo-generate-default-span-names
otel-collector-otel-col-1  |     Kind           : Client
otel-collector-otel-col-1  |     Start time     : 2023-08-31 08:40:42.468092 +0000 UTC
otel-collector-otel-col-1  |     End time       : 2023-08-31 08:40:42.468187 +0000 UTC
otel-collector-otel-col-1  |     Status code    : Unset
otel-collector-otel-col-1  |     Status message :
otel-collector-otel-col-1  | Attributes:
otel-collector-otel-col-1  |      -> app.dummy: Str(VISA ****)
otel-collector-otel-col-1  |      -> redaction.masked.keys: Str(app.dummy)
otel-collector-otel-col-1  |      -> redaction.masked.count: Int(1)
otel-collector-otel-col-1  |    {"kind": "exporter", "data_type": "traces", "name": "logging"}

Expected Result

The redaction processor should consistently match and redact attribute values that fit the specified regex patterns, including numeric values.

Actual Result

Currently, the redaction processor does not effectively match and redact numeric attribute values, leading to inconsistent redaction behavior.

---

We suspect the issue could be related to this line.
It seems that this line returns an empty result if the attribute value is not a string, which could explain why numeric values are not being redacted as expected.

Collector version

0.84.0

Environment information

Environment

• Using Docker image otel/opentelemetry-collector-contrib:0.84.0

OpenTelemetry Collector configuration

No response

Log output

No response

Additional context

No response

[github-actions]

Pinging code owners:

• processor/redaction: @leonsp-ai @dmitryax @mx-psi @TylerHelmuth

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[mx-psi]

Specifically, the redaction regex does not seem to match when the span attribute has only numeric values.

How would you expect the redaction processor to work in this case? Should the redaction processor change the type from Int to string?

[andoniaf]

How would you expect the redaction processor to work in this case? Should the redaction processor change the type from Int to string?

Yes, I think so, as MatchString is expecting a string.

I'm not sure how the attributes are passed to the redactor processor, but apparently if there's only numeric values it comes as an Int, so maybe instead of Value.Str() it should be Value.AsString() to convert it to string for the regex matching.

[mx-psi]

@TylerHelmuth can the transform processor apply the AsString transformation? I don't think the redaction processor should transform the type of attributes since this could lead to surprising/unexpected behavior with other more complex types

[TylerHelmuth]

I agree that the redactionprocessor shouldn't be in the business of transforming telemetry.

We don't have a String() function yet like we do for Int(), but we want one. We'd welcome that addition. In the meantime I think you could use Concat as a workaround.

set(attributes["app.dummy"], Concat([attributes["app.dummy"]], "") where not IsString(attributes["app.dummy"])

[crobert-1]

From my understanding of the comments I'm going to remove the needs triage label, and change it from a bug -> enhancement as the solution is to add a String() function as referenced. Feel free to correct me if I'm misunderstanding.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/redaction: @leonsp-ai @dmitryax @mx-psi @TylerHelmuth

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/redaction: @dmitryax @mx-psi @TylerHelmuth

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[crobert-1]

#29087 was recently filed requesting the same functionality. I'm going to close this issue in favor of that one as the purpose and request is more clear there.

Feel free to let me know if I missed something here.