Zilla Kafka Gateway
Universal Kafka access, governed at the edge.
Zilla Kafka Gateway puts a secure, stateless edge in front of Kafka. Proxy native Kafka clients, connect the clients that don't speak Kafka, and enforce identity, schema, policy, and audit controls without changing your applications or your clusters.
Powering Global Data Driven Organizations
The Problem
Kafka was built for systems, not for governed access at scale.
The wrapper farm
Exposing Kafka to apps, partners, devices, and agents means wrapper services, until the wrapper layer becomes the product.
Custome code
Duplicated logic
Ops overhead
Uneven governance
The governance gap
Isolation, identity, and edge enforcement aren't built in. You build them yourself or go without.
Tenant isolation
Identity end-to-end
Schema at the edge
Per-tenant quotas
Field-level privacy
Audit trails
The Solution
One stateless data plane. Declarative. In your perimeter.
Zilla Kafka Gateway sits at the edge of your Kafka cluster as a stateless container, Kubernetes pod, or AWS AMI. One zilla.yaml defines every protocol, route, identity, schema, and policy.
No database. No persistent state. No coordination between instances.
Stateless by design
Scale horizontally. Restart safely. Run multiple instances with no shared state and no coordination layer between them.
no database
no persistence
Declarative configuration
Kafka access, protocol mediation, schemas, and policies live in one config file. Reload changes without rewriting applications.
zilla.yaml
In your perimeter
Data, credentials, keys, and Kafka traffic stay inside your network. Zilla governs access without moving data into an external platform.
vpc
on-prem
air-gapped
Kafka-native proxying
Proxy Kafka traffic without changing clients.
Zilla is a transparent proxy for Kafka producers, consumers, and Kafka Connect. Clients connect exactly as they would to a broker — only bootstrap.servers changes.
The Kafka protocol stays intact end to end, including produce, fetch, consumer groups, transactions, idempotent producers, and Kafka Connect.
Kafka wire-protocol passthrough
Standard Kafka clients in Java, Go, Python, .NET, Node, and other languages connect without SDKs, drivers, or rewrites.
only bootstrap.servers changes
Identity at the wire
Authenticate Kafka clients with SASL, SCRAM, mTLS, or AWS IAM, then enforce access at the gateway.
sasl
scram
mtls
aws iam
Policy on the passthrough path
Apply configuration rules, schema validation, and data privacy controls before Kafka traffic reaches the cluster.
config
schema
privacy
Data masking and encryption
Encrypt sensitive and PII fields at the gateway before they reach Kafka, then decrypt, redact, or omit them per consumer authorization on read — including fields already stored in the clear.
encrypt on write · redact on read
Virtual Clusters
Segment one physical Kafka cluster into isolated logical clusters for teams, tenants, partners, or environments.
one cluster → many tenants
Dynamic topic aliases
Every client addresses the same topic name; the gateway rewrites it to that client's own internal topic from the authenticated identity — no per-client config.
messages → messages-${identity}
Performance
Close to Kafka's native ceiling.
Baseline Controls at the Edge
Identity, schema, and telemetry before traffic reaches Kafka.
The controls enterprises expect at a boundary, applied on the traffic path, not bolted on behind it.
Identity for every client
Authenticate non-Kafka clients with JWT, Azure AD, or AWS Lambda authorizers.
Authenticate Kafka-native clients with SASL, SCRAM, mTLS, or AWS IAM.
Use identity to authorize routes, topics, tools, tenants, and access patterns.
Schema enforcement
Validate messages against the registry you already run, and reject invalid data at the edge before it reaches Kafka.
Registries: Confluent Schema Registry, Karapace, Apicurio, AWS Glue, and inline filesystem schemas.
Formats: Avro, JSON Schema, Protobuf, and scalar types.
Telemetry
Export Kafka-aware metrics and structured events to Prometheus, OpenTelemetry, stdout, CloudWatch, and Syslog.
Track request duration, response codes, produce and fetch volume, topic access, client identity, and quota violations.
No log spelunking to answer who read what, and when.
Governance
Data quality and governance, enforced where the traffic flows.
Define policy centrally. Enforce it at the gateway. Keep Kafka ACLs and quotas in place and add the controls Kafka cannot provide on its own.
Configuration policy enforcement
Apply guardrails to Kafka nouns: topics, clusters, producers, and consumers. Enforce naming rules, retention boundaries, deprecated API restrictions, client-version requirements, record-size limits, poll-rate limits, and lag protection.
Field-level encryption and crypto-shredding
Encrypt fields before they reach Kafka; decrypt, redact, or omit them on read by the consumer's authorization. Keys stay in your KMS — destroy a per-user KEK for GDPR erasure.
Streaming schema validation
Validate JSON, Avro, and Protobuf messages at near line rate before they reach Kafka. Reject bad data at the edge, not downstream.
Multi-Protocol Mediation
Connect every client that does not speak Kafka.
Kafka data needs to reach more than Kafka clients. Browsers, mobile apps, IoT devices, partner systems, internal services, and AI agents all need governed access to live data. Zilla maps these protocols to Kafka at the edge in the same runtime, with shared configuration, identity, schema, telemetry, and policy controls, while supporting API and schema standards including OpenAPI, AsyncAPI, and Protocol Buffers.
