This repository contains a growing list of self-contained demo scenarios showcasing the recently released Kryptonite for Kafka proxy filter for 🐊 Kroxylicious. Each scenario uses Docker Compose to spin up the minimum viable local stack needed to demonstrate various field-level encryption capabilities applied at the Kafka proxy layer.
- Kroxylicious: is an Apache Kafka® protocol-aware proxy. It can be used to layer uniform behaviours onto a Kafka based system in areas such as data-governance, security, policy enforcement and audit without needing to change either the applications or the Kafka Cluster.
- Kryptonite for Kafka: is a client-side 🔒 field level 🔓 cryptography "suite" for Apache Kafka® offering an Apache Kafka Connect SMT, ksqlDB UDFs, Apache Flink® UDFs, a standalone HTTP API service, and will soon add a proxy filter plugin for Kroxylicious. It's an UNOFFICIAL community project.
| # | Scenario | Description |
|---|---|---|
| 1 | Basic Field-Level Encryption & Decryption | Transparent encryption and decryption of selected JSON payload fields at the proxy layer using a single AES-128-GCM keyset. Kafka console producers and consumers use the proxy endpoint unchanged; direct broker consumers see partially encrypted records only. |
| 2 | JSON Schema Registry + Multiple Keysets | Adds a schema registry into the mix and uses the sample data with a corresponding JSON schema. Also, two keysets are configured to encrypt different payload fields with different keysets. |
| 3 | Security Clearance Levels with Network Isolation and Keysets Separation | Three dedicated Kroxylicious instances (one per clearance level: unclassified, confidential, topsecret) each supposed to run on an isolated network having access only to the keysets their clearance permits. Clients are "forcibly routed" through the matching proxy, which implicitly determines the encrypted fields they are allowed to see in plaintext. |
| 4 | Mixing Different Encryption Semantics Across Payload Fields | Fictional checkout events are serialised in Avro. Five sensitive fields per record are encrypted using three distinct modes: format-preserving encryption (FPE) for the card number, deterministic AES-GCM-SIV for account ID and promo code (enabling correlation without decryption), and probabilistic AES-GCM for cardholder name and gift card ID. Null encryption is applied to the two nullable fields. |
| 5 | Intra-Keyset and Cross-Keyset Key Rotation | Fictional search query logs are encrypted and accumulated over three phases. Phase 1 uses the initial keyset and key id. Phase 2 promotes a different key id within the same keyset (intra-keyset rotation). Phase 3 introduces an entirely new keyset (cross-keyset rotation). The proxy filter decrypts every record in the topic regardless of which key encrypted it. |
| 6 | Multi-Tenant Field Encryption with Separate KEKs and Keyset-based Envelope Encryption | Fictional patient health records for two healthcare tenants are produced to separate Kafka topics. Each tenant has its own KEK keyset and encrypts a different set of fields: tenant_a encrypts three whole-object fields (address, vitals, insurance), while tenant_b encrypts individual array elements within diagnoses and medications (fieldMode: ELEMENT). A single proxy deployment enforces both policies simultaneously via per-topic-pattern field configurations. |
| 7 | Dynamic Key Identifiers for Per-Region Data Encryption | Insurance claim events in Avro format are published to Kafka. Each record carries a region field (EMEA, LATAM, APAC, NA) from which the proxy filter resolves the correct regional keyset at runtime. Three sensitive composite fields (policy_holder, incident, payout_account) are encrypted under the matching regional key, binding each record's ciphertext cryptographically to its region of origin. |