Skip to main content

Signing Processor

Status Maintainers: @hilmarf, @jmacd Source: opentelemetry-collector-contrib

Supported Telemetry

Logs

Overview

The signing processor adds cryptographic integrity attributes to log records. For each log record it computes a canonical JSON hash (RFC 8785 / JCS) over the full record and signs it with an RSA private key. The resulting signature is stored as audit.integrity.value attribute on the record, and the JWA algorithm identifier plus a certificate reference are stored as audit.integrity.algorithm and audit.integrity.certificate on the enclosing Resource. The processor is designed for use with the OpenTelemetry Audit Logging signal and satisfies the Tier-2 Collector integrity-verification requirements defined there.

Configuration

For complete examples of all supported configurations see testdata/config.yaml. For invalid configuration examples used in tests see testdata/config_invalid.yaml.

Key source providers

Note on the env key source: The certificate, private_key, and hmac_key fields hold the actual PEM text or base64-encoded key material, not environment variable names. The collector’s confmap layer expands ${env:VAR_NAME} references before the processor starts, so the processor always receives resolved values. See confmap environment variable substitution for details. Configs that previously passed bare variable names (e.g. certificate: SIGNING_CERT_PEM) will fail at provider construction time.

Output attributes

Per log record

Per Resource (set once per ResourceLogs block)

Signed payload

The processor serialises the following log-record fields into a JSON object, canonicalises it with RFC 8785 (JCS), and signs the result. All audit.integrity.* attributes are excluded so the signature can be verified before those attributes are removed.

Attribute scalar encoding

Attribute values are encoded as follows to keep every scalar type distinct in the signed payload. Each scalar is wrapped in a type-tagged single-key object (e.g. {"intValue":"123"}) so that values of different types never produce identical canonical JSON. Serialization fails with a hard error if the total pre-JCS JSON size exceeds 2 MiB, if the attribute nesting depth exceeds 128 levels, or if the event name, an attribute key, a map key, or a string value is not valid UTF-8. The check exists because json.Marshal would otherwise replace each invalid byte with U+FFFD, and two records differing only in such bytes would share a signature.

Example pipeline

Configuration

Example Configuration


Last generated: 2026-10-05