Overview
This page provides configuration examples for encryption/decryption Interceptor use cases. Find out more about:From our blog: Stop building Kafka encryption libraries Why custom encryption code creates tech debt and how a proxy-based approach eliminates it.
Encryption examples
Schema based encryption examples
- Fields containing specific information with (
keySecretId,algorithm,tagsmatch) will be encrypted. - Field would be encrypted with the associated
keySecretId,algorithm, if any missed, would be encrypted with the associated default ones in the Interceptor configuration. - Field would be encrypted with defaultSecret, defaultAlgorithm when
tagshas element with is in the Interceptor configuration.
conduktor.):
passwordwould be encrypted with the associated keySecretId, algorithm etc.visawould be encryption with the associated keySecretId and the default algorithm provided in the Interceptor configuration.locationwould be encrypted with defaultSecret, defaultAlgorithm because tags hasPIIwith is in the Interceptor configuration.- fields containing no specific information (
keySecretId,algorithm,tagswithout match) are left untouched.
conduktor.):
conduktor.):
In Protobuf, since we are using the Confluent schema registry, we use the (confluent.field_meta).params (with type map<string, string) for field options. Here’s how it can be defined:
Simple encrypt on produce
- curl
- Conduktor CLI
Field level encryption on produce
- curl
- Conduktor CLI
Field-level encryption on produce with secured template
- curl
- Conduktor CLI
Schema-based field level encryption on produce
- curl
- Conduktor CLI
Full message level encryption on produce
- curl
- Conduktor CLI
Full message level encryption on produce with secured template
- curl
- Conduktor CLI
On consume encryption plugins (
FetchEncryptPlugin and FetchEncryptSchemaBasedPlugin) were removed in Gateway v3.19.0. See removed Interceptors for their documentation.Decryption examples
Decrypt all fields
Decrypt all fields with secured template
Decrypt specific fields
Decrypt specific fields with secured template
Decrypt full message
Decrypt full message with secured template
Stack encryption Interceptors
You can combine multiple encryption Interceptors to apply different encryption strategies to different parts of your data. A common pattern is to use field-level encryption for known sensitive fields, with full payload encryption as a fallback for any messages that don’t match the field-level rules. This is controlled by theerrorPolicy setting. When set to skip_already_encrypted, an encryption Interceptor skips records that were already encrypted by a previous Interceptor in the chain.
Interceptors execute in priority order (lowest number first). To stack them:
- Set a lower priority (runs first) for your field-level encryption Interceptor
- Set a higher priority (runs second) for your full payload encryption Interceptor
- Set
errorPolicy: skip_already_encryptedon the full payload Interceptor so it only encrypts records that weren’t already handled
Field-level encryption with full payload fallback
In this example, thepassword and visa fields are encrypted individually. Any message that doesn’t have field-level encryption applied (for example, a message without those fields) gets full payload encryption as a fallback.
- Conduktor CLI
- curl
- A message arrives on a
sensitive-.*topic - The field-level Interceptor (priority 1) runs first. If the message contains
passwordorvisafields, those fields are encrypted and the record is flagged with encryption headers - The full payload Interceptor (priority 2) runs second. Because
errorPolicyis set toskip_already_encrypted, it skips any record that was already encrypted by the field-level Interceptor. Records that weren’t field-level encrypted get full payload encryption - On consume, a single
DecryptPluginhandles decryption for both encryption types
If you also offload large messages to cloud storage, see Combine with encryption for the recommended priority order so ciphertext, not plaintext, lands in your cloud storage.