Connect

schema_registry_encode

Automatically encodes and validates messages with schemas from a Confluent Schema Registry service.

This processor uses the Franz Kafka Schema Registry client.

Introduced in version 3.58.0.

  • Common

  • Advanced

processor:
  label: ""
  schema_registry_encode:
    url: "" # No default (required)
    subject: "" # No default (required)
    refresh_period: 10m
    schema_metadata: ""
    format: "" # No default (optional)
    avro:
      raw_json: false # No default (optional)
      record_name: ""
      namespace: ""
processor:
  label: ""
  schema_registry_encode:
    url: "" # No default (required)
    subject: "" # No default (required)
    refresh_period: 10m
    schema_metadata: ""
    format: "" # No default (optional)
    normalize: true
    avro:
      raw_json: false # No default (optional)
      input_encoding: auto
      record_name: ""
      namespace: ""
    oauth:
      enabled: false
      consumer_key: ""
      consumer_secret: ""
      access_token: ""
      access_token_secret: ""
    basic_auth:
      enabled: false
      username: ""
      password: ""
    jwt:
      enabled: false
      private_key_file: ""
      signing_method: ""
      claims: {}
      headers: {}
    tls:
      skip_cert_verify: false
      enable_renegotiation: false
      root_cas: ""
      root_cas_file: ""
      client_certs: []

Encodes messages automatically from schemas obtains from a Confluent Schema Registry service by polling the service for the latest schema version for target subjects.

If a message fails to encode under the schema then it will remain unchanged and the error can be caught using error-handling methods.

Avro, Protobuf and JSON schemas are supported, all are capable of expanding from schema references as of v4.22.0.

Avro JSON format

By default, this processor expects documents formatted as Avro JSON when encoding with Avro schemas. In this format, the value of a union is encoded in JSON as follows:

  • If the union’s type is null, it is encoded as a JSON null.

  • Otherwise, the union is encoded as a JSON object with one name/value pair. The name is the type’s name, and the value is the recursively-encoded value. The user-specified name is used for Avro’s named types (record, fixed, or enum). For other types, the type name is used.

For example, the union schema ["null","string","Transaction"], where Transaction is a record name, would encode:

  • A null as a JSON null

  • The string "a" as {"string": "a"}

  • A Transaction instance as {"Transaction": {…​}}, where {…​} indicates the JSON encoding of a Transaction instance

Alternatively, you can consume documents in standard/raw JSON format by setting the field avro_raw_json to true.

Known issues

Important! There is an outstanding issue in the avro serializing library that Redpanda Connect uses which means it doesn’t encode logical types correctly. It’s still possible to encode logical types that are in-line with the spec if avro_raw_json is set to true, though now of course non-logical types will not be in-line with the spec.

Protobuf format

This processor encodes Protobuf messages either from any format parsed within Redpanda Connect (encoded as JSON by default), or from raw JSON documents. For more information about the JSON mapping of Protobuf messages, see the Protocol Buffers documentation.

Multiple message support

When a target subject presents a Protobuf schema that contains multiple messages it becomes ambiguous which message definition a given input data should be encoded against. In such scenarios Redpanda Connect will attempt to encode the data against each of them and select the first to successfully match against the data, this process currently ignores all nested message definitions. In order to speed up this exhaustive search the last known successful message will be attempted first for each subsequent input.

We will be considering alternative approaches in future so please get in touch with thoughts and feedback.

Fields

avro

Configuration for Avro encoding.

Requires version 4.83.0 or later.

Type: object

avro.input_encoding

How the values in each message should be read.

Avro JSON and plain JSON disagree about strings, and neither reading is a superset of the other. Avro JSON spells a bytes or fixed value as one codepoint per byte, so the unscaled decimal 0x21 is the string "!"; the plain reading takes a string for a decimal as decimal notation, so "3.33" means 3.33. The same JSON string is therefore a different value under each, and only the pipeline knows which was meant.

  • auto (the default) picks the reader from the form each message arrives in: a raw payload is read as Avro JSON, a structured message as Go values. This is right for schema_registry_decode feeding this processor directly, and for CDC sources, but a processor in between (a mapping, a branch) parses the payload and leaves the message structured, at which point its Avro JSON values are read the plain way and a bytes-backed decimal fails to encode.

  • avro_json reads every message as Avro JSON. Set this when the data came from schema_registry_decode, including when something between the two processors has parsed it. A message that carries Go values Avro JSON has no spelling for (a []byte from content() or decode("base64"), or the []byte and time.Time values that preserve_logical_types produces for bytes, fixed and timestamp fields) is rejected rather than encoded as the wrong value, so a pipeline that mixes those with Avro JSON values has no mode that reads both: map such fields to their Avro JSON spelling first, or split the encode.

  • native reads every message as Go and plain JSON values. Set this for hand-written JSON and for sources that spell decimals in decimal notation.

This is independent of raw_json, which does not affect how values are read.

Requires version 4.108.0 or later.

Type: string

Default: auto

Options: auto, avro_json, native

avro.namespace

The Avro namespace for the root record type when encoding from a common schema (schema_metadata mode).

Type: string

Default: ""

avro.raw_json

Whether messages encoded in Avro format should be parsed as normal JSON rather than Avro JSON. Overrides the deprecated top-level avro_raw_json when set.

Type: bool

avro.record_name

The name to use for the root Avro record type when encoding from a common schema (schema_metadata mode). If empty, derived from the subject.

Type: string

Default: ""

basic_auth

Configure basic authentication for requests from this component.

Requires version 4.7.0 or later.

Type: object

basic_auth.enabled

Whether to use basic authentication in requests.

Type: bool

Default: false

basic_auth.password

The password to use for authentication. Used together with username for basic authentication.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Type: string

Default: ""

basic_auth.username

The username of the account credentials to authenticate as. Used together with password for basic authentication.

Type: string

Default: ""

format

The encoding format to use when converting a common schema from metadata. Required when schema_metadata is set.

Requires version 4.83.0 or later.

Type: string

Options: avro, json_schema

jwt

Beta

Configure JSON Web Token (JWT) authentication. This feature is in beta and may change in future releases. JWTs provide secure, stateless authentication between services.

Requires version 4.7.0 or later.

Type: object

jwt.claims

A map of claims to include in the JWT. Claims pass the identity of the authenticated entity to the service provider.

Type: object

Default: {}

jwt.enabled

Whether to use JWT authentication in requests.

Type: bool

Default: false

jwt.headers

Additional key-value pairs to include in the JWT header (optional). These headers provide extra metadata for JWT processing.

Type: object

Default: {}

jwt.private_key_file

Path to a file containing the PEM-encoded private key using PKCS#1 or PKCS#8 format. The private key must be compatible with the algorithm specified in the signing_method field.

Type: string

Default: ""

jwt.signing_method

The cryptographic algorithm used to sign the JWT. Supported algorithms are RS256, RS384, RS512, and EdDSA. This algorithm must be compatible with the private key specified in the private_key_file field.

Type: string

Default: ""

normalize

Whether to normalize the schema before registering with the schema registry (schema_metadata mode only).

Requires version 4.83.0 or later.

Type: bool

Default: true

oauth

Configure OAuth version 1.0 authentication for secure API access.

Requires version 4.7.0 or later.

Type: object

oauth.access_token

The value used to gain access to the protected resources on behalf of the user.

Type: string

Default: ""

oauth.access_token_secret

The secret that establishes ownership of the access_token in OAuth 1.0 authentication.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Type: string

Default: ""

oauth.consumer_key

The value used to identify this component or client to the service provider.

Type: string

Default: ""

oauth.consumer_secret

The secret that establishes ownership of the consumer key in OAuth 1.0 authentication.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Type: string

Default: ""

oauth.enabled

Whether to enable OAuth version 1.0 authentication for requests.

Type: bool

Default: false

refresh_period

The period after which a schema is refreshed for each subject, this is done by polling the schema registry service.

Type: string

Default: 10m

# Examples:
refresh_period: 60s

# ---

refresh_period: 1h

schema_metadata

When set, the processor reads a schema in benthos common schema format from this metadata key on each message, converts it to the format specified by format, registers it with the schema registry under the configured subject, and encodes the message. When empty (the default), the processor pulls the latest schema from the registry instead.

Requires version 4.83.0 or later.

Type: string

Default: ""

subject

The schema subject to derive schemas from.

This field supports interpolation functions.

Type: string

# Examples:
subject: foo

# ---

subject: ${! meta("kafka_topic") }

tls

Configure Transport Layer Security (TLS) settings to secure network connections. This includes options for standard TLS as well as mutual TLS (mTLS) authentication where both client and server authenticate each other using certificates. Key configuration options include client_certs for mTLS authentication, root_cas/root_cas_file for custom certificate authorities, and skip_cert_verify for development environments.

Type: object

tls.client_certs[]

A list of client certificates for mutual TLS (mTLS) authentication. Configure this field to enable mTLS, authenticating the client to the server with these certificates.

Certificate pairing rules: For each certificate item, provide either:

  • Inline PEM data using both cert and key or

  • File paths using both cert_file and key_file.

Mixing inline and file-based values within the same item is not supported.

Type: array<object>

Default: []

# Examples:
client_certs:
  - cert: foo
    key: bar


# ---

client_certs:
  - cert_file: ./example.pem
    key_file: ./example.key

tls.client_certs[].cert

The plaintext certificate to use for TLS authentication. Must be paired with the corresponding private key in the key field when using inline PEM data for mTLS client certificates.

Type: string

Default: ""

tls.client_certs[].cert_file

The path to a file containing the certificate to use for TLS authentication. Must be paired with the corresponding private key file in the key_file field when using file-based configuration for mTLS client certificates.

Type: string

Default: ""

tls.client_certs[].key

Private key for mTLS client certificate as inline PEM data. Must correspond to the client certificate specified in the cert field. Use this field together with cert when providing certificate data inline rather than through files.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Type: string

Default: ""

tls.client_certs[].key_file

Path to private key file for mTLS client certificate in PEM format. Must correspond to the client certificate specified in the cert_file field. Use this field together with cert_file when loading certificate data from files.

Type: string

Default: ""

tls.client_certs[].password

The password to use for the private key (specified in the key or key_file fields), if it is password-protected. The PKCS#1 and PKCS#8 formats are supported. Supports environment variable interpolation for secure password management.

The pbeWithMD5AndDES-CBC algorithm is obsolete and not supported for the PKCS#8 format. This algorithm does not authenticate the ciphertext, making it vulnerable to padding oracle attacks that can let an attacker recover the plaintext.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Requires version 4.3.0 or later.

Type: string

Default: ""

# Examples:
password: foo

# ---

password: ${KEY_PASSWORD}

tls.enable_renegotiation

Whether to allow the remote server to repeatedly request renegotiation. Enable this option if you’re seeing the error message local error: tls: no renegotiation.

Type: bool

Default: false

tls.root_cas

Specify a root certificate authority to use (optional). This is a string that represents a certificate chain from the parent-trusted root certificate, through possible intermediate signing certificates, to the host certificate. Use either this field for inline certificate data or root_cas_file for file-based certificate loading.

This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Secrets.

Type: string

Default: ""

# Examples:
root_cas: |-
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----

tls.root_cas_file

Specify the path to a root certificate authority file (optional). This is a file, often with a .pem extension, which contains a certificate chain from the parent-trusted root certificate, through possible intermediate signing certificates, to the host certificate. Use either this field for file-based certificate loading or root_cas for inline certificate data.

Type: string

Default: ""

# Examples:
root_cas_file: ./root_cas.pem

tls.skip_cert_verify

Whether to skip server-side certificate verification. Set to true only for testing environments as this reduces security by disabling certificate validation. When using self-signed certificates or in development, this may be necessary, but should never be used in production. Consider using root_cas or root_cas_file to specify trusted certificates instead of disabling verification entirely.

Type: bool

Default: false

url

The base URL of the schema registry service.

Type: string