Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.conduktor.io/llms.txt

Use this file to discover all available pages before exploring further.

Interceptors are plugins that intercept and modify Kafka requests and responses in real time. They help enforce policies, protect data, and add functionality without changing your applications or Kafka configuration.

​
What Interceptors do

Interceptors can:
  • Encrypt and decrypt message fields or entire payloads
  • Block or skip records that don’t meet data quality rules
  • Enforce producer settings like acks or compression
  • Control topic creation parameters like replication factor or partition count
  • Transform message content or headers

​
How they work

Each Interceptor has a priority field — a number where lowest runs first. The same numeric order applies on both produce and consume; ordering doesn’t reverse between directions. Priorities are typically spaced apart (for example, 100, 200, 300) so you can insert Interceptors between existing ones without renumbering. Interceptors fire on different paths depending on what they do:
  • Produce-only — for example, EncryptPlugin runs as records flow from client to broker.
  • Consume-only — for example, DecryptPlugin runs as records flow from broker to client.
  • Both paths — for example, LargeMessageHandlingPlugin runs as records flow from client to broker and broker to client.
For example, an EncryptPlugin, LargeMessageHandlingPlugin, and DecryptPlugin configured on the same topic share one priority order across both paths: 
# Priority 100: encrypt on produce
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: myEncryptPlugin
  scope:
    vCluster: passthrough
spec:
  pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
  priority: 100
  config:
    topic: "topic.*"
    kmsConfig:
      vault:
        uri: http://vault:8200
        token: ${VAULT_TOKEN}
    recordValue:
      payload:
        keySecretId: vault-kms://vault:8200/transit/keys/payload-key
        algorithm: AES128_GCM
---
# Priority 200: offload large messages to cloud storage
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: myLargeMessageHandlingPlugin
  scope:
    vCluster: passthrough
spec:
  pluginClass: io.conduktor.gateway.interceptor.LargeMessageHandlingPlugin
  priority: 200
  config:
    topic: "topic.*"
    minimumSizeInBytes: 1024
    localDiskDirectory: myStorage/
    s3Config:
      bucketName: myBucketName
      uri: http://myexampleuri
      region: us-east-1
---
# Priority 300: decrypt on consume
apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: myDecryptPlugin
  scope:
    vCluster: passthrough
spec:
  pluginClass: io.conduktor.gateway.interceptor.DecryptPlugin
  priority: 300
  config:
    topic: "topic.*"
    kmsConfig:
      vault:
        uri: http://vault:8200
        token: ${VAULT_TOKEN}
For why this ordering matters when offloading encrypted records to cloud storage, see Combine with encryption. Interceptors can also be:
  • Scoped — apply to specific , or
  • Overridden — more specific scopes take precedence over broader ones
Gateway applies Interceptors dynamically based on which client connects, so different teams can have different policies without separate clusters.