Conduktor Gateway
Routen. Schützen. Transformieren.
Ein Kafka-Proxy, der Platform-Teams die Kontrolle gibt, die sie sich schon immer gewünscht haben – ohne dass Entwickler eine einzige Zeile Code ändern müssen.

Erweitern Sie Ihre Infrastruktur.
Kafka ist leistungsstark, wurde aber nicht für Governance, Sicherheit oder Policy-Durchsetzung entwickelt. Ein Kafka Gateway schließt diese Lücke, damit Platform-Teams Kafka an ihre Anforderungen anpassen können – und nicht umgekehrt.
Für Platform-Teams Skalieren Sie Kafka teamübergreifend, ohne Infrastruktur oder Komplexität zu vervielfachen.
Für Sicherheit & Compliance Setzen Sie Verschlüsselung und Datenrichtlinien auf Infrastrukturebene durch – nicht im Anwendungscode.
Was ist Conduktor Gateway?
Conduktor Gateway ist ein Kafka-Proxy, der zwischen Ihren Client-Anwendungen und Ihren Kafka-Brokern sitzt. Er bietet Platform-Teams einen zentralen Kontrollpunkt für Sicherheit, Routing, Datenqualität und Multi-Tenancy – ohne Änderungen am Anwendungscode.
Natives Kafka-Protokoll
Gateway spricht das Kafka-Wire-Protokoll. Clients verbinden sich damit genau wie mit einem Broker. Aktualisieren Sie einfach bootstrap.servers und der Proxy übernimmt Authentifizierung, Verschlüsselung, Routing und Observability transparent.
Kontrolle auf Infrastrukturebene
Fügen Sie Funktionen hinzu, die nativ nicht verfügbar sind – wie feldbasierte Verschlüsselung, virtuelle Cluster, SQL-basierte Topic-Views und Chaos-Testing –, ohne jedes Anwendungsteam um eine individuelle Implementierung zu bitten.
Keine Anwendungsänderungen
Jede Produce- und Consume-Anfrage läuft durch den Proxy. Richtlinien werden auf Infrastrukturebene angewendet, sodass Platform-Teams Standards für alle Teams von einem Ort aus durchsetzen können.
Benötigen Sie nur netzwerkübergreifenden Zugriff auf Kafka? Probieren Sie Gateway Community Edition, unseren kostenlosen Kafka-Proxy. Er verbindet Clients mit Clustern in anderen VPCs, Clouds oder privaten Netzwerken – ohne Änderungen an Ihren Brokern oder Anmeldedaten.
Gateway-Anwendungsfälle
Routing, Multi-Tenancy & Performance
Beseitigen Sie Netzwerkbarrieren, stellen Sie isolierte Kafka-Umgebungen ohne separate Cluster bereit und optimieren Sie den Durchsatz auf Proxy-Ebene.
Verbinden ohne Code-Änderungen
Beseitigen Sie Netzwerkbarrieren für die Kafka-Konnektivität mit Kafka-Proxy-Routing, zentralisieren Sie die Authentifizierung über OIDC-Integration und setzen Sie feingranulare Zugriffskontrollen durch, die über native ACLs hinausgehen.
- Netzwerkübergreifende Konnektivität – Client-Verbindungen werden über Gateway geroutet, ohne Client-Konfigurationsänderungen
- Zentralisierte Authentifizierung – Integration mit externen OIDC-Systemen für einheitliche Zugangskontrolle in hybriden Deployments
- Anwendungs-Audit-Trails – Verfolgung jeder Aktion über Kafka-Ressourcen hinweg zur Erfüllung von SOC2-, ISO 27001- und GDPR-Anforderungen
# Gateway Configuration
gateway:
environment:
GATEWAY_SECURITY_MODE: GATEWAY_MANAGED
GATEWAY_SECURITY_PROTOCOL: SASL_PLAINTEXT
# OIDC Provider Settings
GATEWAY_OAUTH_JWKS_URL: "https://your-idp.com/.well-known/jwks.json"
GATEWAY_OAUTH_EXPECTED_ISSUER: "https://your-idp.com"
GATEWAY_OAUTH_EXPECTED_AUDIENCES: "kafka-gateway"
GATEWAY_OAUTH_SUB_CLAIM_NAME: "sub"
# Map OIDC identities to Gateway Service Accounts
apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
name: my-application
spec:
type: EXTERNAL
externalNames:
- "oauth-subject-id-from-token" # Value from 'sub' claim in JWT// Audit log event
{
"id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"type": "APIKEYS_REQUEST",
"time": "2024-10-15T14:30:45.123Z",
"source": "//kafka/cluster/production",
"authenticationPrincipal": "tenant-acme",
"userName": "order-service",
"connection": {
"localAddress": "172.17.0.2:6969",
"remoteAddress": "192.168.1.42:52341"
},
"eventData": {
"apiKeys": "PRODUCE",
"topics": [
{ "name": "orders", "partition": 0 },
{ "name": "orders", "partition": 1 }
]
},
"specVersion": "0.1.0"
}Mandanten von Clustern entkoppeln
Stellen Sie mehreren Teams isolierte Kafka-Umgebungen bereit, ohne die Kosten separater Cluster, beseitigen Sie das Chaos bei Topic-Namen und reduzieren Sie die Anzahl der Partitionen erheblich.
- Virtuelle Cluster – Bereitstellung mehrerer logischer Kafka-Cluster auf einem einzelnen physischen Cluster mit isolierten Namespaces und ACL-Grenzen
- Topic-Konzentration – Zusammenführung von Topics mit geringem Volumen in gemeinsam genutzte physische Topics, wodurch die Partitionsanzahl um mehr als 90 % reduziert wird
- Topic-Aliase – Zugriff auf Topics über Alias-Namen, um sie ohne Client-Änderungen umzubenennen oder interne Bezeichnungen zu verbergen
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
name: payments-team
spec:
type: Standard
aclEnabled: true
superUsers:
- payments-admin
apiVersion: gateway/v2
kind: VirtualCluster
metadata:
name: orders-team
spec:
type: Standard
aclEnabled: true
superUsers:
- orders-admin
apiVersion: gateway/v2
kind: AliasTopic
metadata:
name: customers
vCluster: partner-team
spec:
physicalName: internal-crm-customers
apiVersion: gateway/v2
kind: AliasTopic
metadata:
name: orders
vCluster: partner-team
spec:
physicalName: internal-billing-ordersLast effizient bewältigen
Reduzieren Sie die Broker-Last durch wiederholte Lesevorgänge, verarbeiten Sie überdimensionierte Payloads ohne Auswirkungen auf die Cluster-Performance und stellen Sie gefilterte Topic-Views ohne die Komplexität von Stream-Processing bereit.
- SQL-Topics – Erstellung schreibgeschützter virtueller Topics mit SQL-basierter Filterung und Projektionen auf Gateway-Ebene
- Caching – Bereitstellung häufig abgerufener Nachrichten aus dem Gateway-Cache, um die Broker-Last bei hochfrequenten Lesezugriffen zu reduzieren
- Auslagerung großer Nachrichten – Automatische Auslagerung von Nachrichten, die Größenschwellenwerte überschreiten, nach S3 oder Azure Blob Storage
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: sql-filter-adults
spec:
pluginClass: io.conduktor.gateway.interceptor.VirtualSqlTopicPlugin
priority: 100
config:
virtualTopic: customers-adult
statement: |
SELECT firstName, lastName, email, country
FROM customers
WHERE age >= 18 AND country = 'US'
schemaRegistryConfig:
host: http://schema-registry:8081apiVersion: gateway/v2
kind: Interceptor
metadata:
name: cache-high-traffic-topics
spec:
pluginClass: io.conduktor.gateway.interceptor.CacheInterceptorPlugin
priority: 100
config:
topic: "events.*"
cacheConfig:
type: IN_MEMORY
inMemConfig:
cacheSize: 1000
expireTimeMs: 60000apiVersion: gateway/v2
kind: Interceptor
metadata:
name: offload-large-messages-s3
spec:
pluginClass: io.conduktor.gateway.interceptor.LargeMessageHandlingPlugin
priority: 100
config:
topic: "media.*"
minimumSizeInBytes: 1048576
localDiskDirectory: /tmp/kafka-offload
s3Config:
bucketName: kafka-large-messages
region: us-east-1Ihre Schema Registry steuern
Fügen Sie Ihrer Schema Registry Authentifizierung, Zugangskontrolle und Observability mit einem Drop-in-Kafka-Proxy hinzu, der Governance bei jeder Operation durchsetzt.
- JWT/OIDC-Authentifizierung – Validierung von Tokens Ihres bestehenden Identity-Providers, bevor eine Anfrage die Registry erreicht
- Subjektbezogene Zugriffskontrollen – Durchsetzung von Lese- und Schreibberechtigungen mit exakter Übereinstimmung, Platzhalter- und Präfix-Matching
- Vollständige Observability – Nachverfolgung jeder Operation mit OpenTelemetry, Messung mit Prometheus und Logging in strukturiertem JSON
# docker-compose.yml
schema-registry-proxy:
ports:
- "8080:8080"
- "9464:9464" # Prometheus metrics
environment:
# Schema Registry backend
CONFLUENT_SCHEMA_REGISTRY_URL: http://schema-registry:8081
# JWT authentication via OIDC provider
AUTH_PROVIDER: jwt
JWT_JWKS_URL: http://keycloak:8080/realms/kafka/protocol/openid-connect/certs
JWT_SUBJECT_CLAIM_NAME: sub
# Dynamic permissions via Kafka
AUTH_USE_REACTIVE_CONFIG: true
KAFKA_BOOTSTRAP_SERVERS: kafka:9092
# OpenTelemetry tracing
OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4317# Permission format (Kafka topic: _conduktor_srp_commands)
# Key: service account name
# Value: permission entries
# Admin — full access to all subjects
{ "permissions": [
{ "subject": "*",
"permissionType": "WRITE" }
]}
# Payments team — prefix matching
{ "permissions": [
{ "subject": "payments-*",
"permissionType": "WRITE" },
{ "subject": "orders-*",
"permissionType": "READ" }
]}
# Analytics — read-only, all subjects
{ "permissions": [
{ "subject": "*",
"permissionType": "READ" }
]}# Get a JWT token (client credentials flow)
TOKEN=$(curl -s -X POST \
http://keycloak:8080/realms/kafka/protocol/openid-connect/token \
-d "grant_type=client_credentials" \
-d "client_id=payments-service" \
-d "client_secret=secret" | jq -r '.access_token')
# Register a schema through the proxy
curl -X POST http://localhost:8080/subjects/payments-value/versions \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"schema": "{\"type\":\"record\",\"name\":\"Payment\",\"fields\":[{\"name\":\"id\",\"type\":\"string\"}]}"}'
# Response: {"id": 1}
# Metrics: schema_registry_requests_total +1
# Trace: full span in Jaeger/OTLPResilienz & Disaster Recovery
Verhindern Sie, dass Entwickler-Fehlkonfigurationen Ihre Plattform destabilisieren, gewährleisten Sie Betriebskontinuität bei Ausfällen und validieren Sie die Fehlertoleranz durch kontrollierte Tests.
Fehlkonfigurationen verhindern
Beseitigen Sie Noisy-Neighbor-Probleme und Konfigurationsdrift mit Kafka Gateway-Schutzmaßnahmen, die Namenskonventionen, Aufbewahrungslimits, Quotas und Replikationsregeln durchsetzen, bevor Probleme die Produktion erreichen.
- Konfigurationsrichtlinien – Durchsetzung von Topic-Namenskonventionen, Aufbewahrungslimits, Replikationsregeln und Schema-Anforderungen bei Bereitstellung und Laufzeit
- Traffic-Steuerung & Quotas – Durchsetzung von Bandbreiten- und Ratenbegrenzungen pro Mandant oder Cluster zur Vermeidung von Noisy-Neighbor-Problemen
- Producer- & Consumer-Richtlinien – Sicherstellung von Acks-, Komprimierungs- und Idempotenzanforderungen für alle Producer sowie Steuerung des Fetch-Verhaltens von Consumern
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: topic-governance-policy
spec:
pluginClass: io.conduktor.gateway.interceptor.safeguard.CreateTopicPolicyPlugin
priority: 100
config:
namingConvention:
value: "^[a-z]+-[a-z]+-[a-z]+$"
action: BLOCK
numPartition:
min: 3
max: 12
action: OVERRIDE
overrideValue: 6
replicationFactor:
min: 3
max: 3
action: BLOCK
retentionMs:
min: 86400000
max: 604800000
action: OVERRIDE
overrideValue: 259200000apiVersion: gateway/v2
kind: Interceptor
metadata:
name: producer-rate-limit
scope:
vCluster: payments-team
spec:
pluginClass: io.conduktor.gateway.interceptor.safeguard.ProducerRateLimitingPolicyPlugin
priority: 100
config:
maximumBytesPerSecond: 10485760
action: BLOCK
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: consumer-rate-limit
scope:
vCluster: payments-team
spec:
pluginClass: io.conduktor.gateway.interceptor.safeguard.ConsumerRateLimitingPolicyPlugin
priority: 100
config:
maximumBytesPerSecond: 52428800Sicher migrieren und wiederherstellen
Gewährleisten Sie Betriebskontinuität bei Cluster-Migrationen und Failover durch transparente Kafka-Proxy-Umleitung und validieren Sie die Fehlertoleranz durch kontrolliertes Chaos-Testing.
- Cluster-Wechsel & Failover – Migration von Anwendungen zwischen Clustern oder Wechsel zu Failover-Infrastruktur ohne Änderungen an der Anwendungskonfiguration oder teamübergreifende Koordination
- Chaos Engineering – Einschleusung von Latenz, Protokollfehlern und Nachrichtenkorruption über Gateway-Interceptors, um Resilienz zu testen, ohne die Produktion zu stören
# Gateway cluster configuration
config:
main:
bootstrap.servers: kafka-primary:9092
security.protocol: SASL_SSL
sasl.mechanism: PLAIN
failover:
bootstrap.servers: kafka-secondary:9092
gateway.roles: failover
# Switch from main → failover
curl -X POST 'http://localhost:8888/gateway/v2/cluster-switching' \
-H 'Content-Type: application/json' \
-d '{"fromPhysicalCluster": "main", "toPhysicalCluster": "failover"}'# Chaos testing interceptor
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: chaos-broken-broker
spec:
pluginClass: io.conduktor.gateway.interceptor.chaos.SimulateBrokenBrokersPlugin
priority: 100
config:
rateInPercent: 100
errorMap:
FETCH: UNKNOWN_SERVER_ERROR
PRODUCE: CORRUPT_MESSAGEDatenschutz
Steuern Sie Nachrichten-Metadaten, setzen Sie Datenqualität durch, schützen Sie sensible Felder und verifizieren Sie die Nachrichtenintegrität auf Proxy-Ebene.
Schlechte Daten an der Quelle stoppen
Stoppen Sie fehlerhafte und nicht konforme Daten an der Quelle, anstatt Qualitätsprobleme erst zu entdecken, nachdem sie nachgelagerte Systeme beeinträchtigt haben.
- Datenqualitätserkennung – Bewertung der durch Gateway fließenden Daten auf Einhaltung von Validierungsregeln und Qualitätsstandards
- Datenqualitätsdurchsetzung – Blockierung, Umleitung oder Markierung von Nachrichten, die Qualitätsregeln verletzen, bevor sie Kafka erreichen
{
"name": "myDataQualityProducerPlugin",
"pluginClass": "io.conduktor.gateway.interceptor.safeguard.DataQualityProducerPlugin",
"priority": 100,
"config": {
"statement": "SELECT x FROM orders WHERE amount_cents > 0 AND amount_cents < 1000000",
"schemaRegistryConfig": {
"host": "http://schema-registry:8081"
},
"action": "BLOCK_WHOLE_BATCH",
"deadLetterTopic": "dead-letter-topic",
"addErrorHeader": false
}
}
Konsistent über alle Apps verschlüsseln
Gewährleisten Sie konsistente Verschlüsselung über alle Anwendungen hinweg mit zentralisierter KMS-Durchsetzung auf Kafka Gateway-Ebene und ermöglichen Sie Analysen sensibler Daten durch feldbasierte Tokenisierung.
- Zentralisierte Verschlüsselung – Durchsetzung der Verschlüsselung mit einer standardisierten KMS-Verbindung zur Vermeidung von Konfigurationsdrift und Ermöglichung von Crypto-Shredding für GDPR-Compliance
- Multi-Cloud-KMS-Integration – Verbindung mit Vault, AWS KMS, Azure Key Vault, GCP KMS oder Fortanix für PCI-DSS-, HIPAA- und GDPR-Compliance
- Feldbasierte Verschlüsselung – Verschlüsselung sensibler Felder mit schemabasierter Zielsetzung, während nicht sensible Daten lesbar bleiben
- Tokenisierung – Ersetzen sensibler Werte durch Tokens unter Beibehaltung des Formats für Analysen
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: encrypt-pii-fields
spec:
pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
priority: 100
config:
topic: "customers.*"
recordValue:
fields:
- fieldName: ssn
keySecretId: "vault-kms://vault:8200/transit/keys/pii-key"
algorithm: AES256_GCM
- fieldName: creditCard.number
keySecretId: "vault-kms://vault:8200/transit/keys/payment-key"
algorithm: AES256_GCM
- fieldName: email
keySecretId: "in-memory-kms://email-key"
algorithm: AES128_GCM
kmsConfig:
vault:
uri: http://vault:8200
type: TOKEN
token: ${VAULT_TOKEN}apiVersion: gateway/v2
kind: Interceptor
metadata:
name: encrypt-with-kms
spec:
pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
priority: 100
config:
topic: ".*"
recordValue:
fields:
- fieldName: ssn
keySecretId: "vault-kms://..."
- fieldName: payment.cardNumber
keySecretId: "aws-kms://..."
- fieldName: healthRecord
keySecretId: "azure-kms://..."
kmsConfig:
vault:
uri: http://vault:8200
type: APP_ROLE
aws:
basicCredentials:
accessKey: ${AWS_ACCESS_KEY}
azure:
tokenCredential:
tenantId: ${AZURE_TENANT_ID}Nachrichtenintegrität verifizieren
Verifizieren Sie die Authentizität von Nachrichten und erkennen Sie Manipulationen, um Audit- und Custody-Chain-Anforderungen zu erfüllen.
- Kryptografische Signierung – Signierung von Nachrichten am Gateway zur Erkennung von Manipulationen und Verifizierung des Nachrichtenursprungs für Compliance-Anforderungen
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: sign-messages
spec:
pluginClass: io.conduktor.gateway.interceptor.integrity.ProduceIntegrityPolicyPlugin
priority: 100
config:
topic: "transactions.*"
secretKeyUri: "secret/data/signing-key#key"
keyProviderConfig:
vault:
uri: https://vault:8200
type: TOKEN
token: ${VAULT_TOKEN}Nachrichten-Metadaten steuern
Stellen Sie sicher, dass Nachrichten-Metadaten ohne Anwendungsänderungen den Unternehmensstandards entsprechen.
- Header- & Nachrichtenverarbeitung – Einfügen, Ändern oder Entfernen von Nachrichten-Headern zur zentralen Transformation und Steuerung von Metadaten
apiVersion: gateway/v2
kind: Interceptor
metadata:
name: inject-tracking-headers
spec:
pluginClass: io.conduktor.gateway.interceptor.DynamicHeaderInjectionPlugin
priority: 100
config:
topic: "orders.*"
headers:
X-Source-Region: "${GATEWAY_REGION}"
X-Gateway-Timestamp: "${timestamp}"
overrideIfExists: trueapiVersion: gateway/v2
kind: Interceptor
metadata:
name: remove-internal-headers
spec:
pluginClass: io.conduktor.gateway.interceptor.safeguard.MessageHeaderRemovalPlugin
priority: 100
config:
topic: ".*"
headerKeyRegex: "^X-Internal-.*"Externer Datenaustausch
Teilen Sie Kafka-Daten mit externen Partnern, ohne Ihre Infrastruktur übermäßig offenzulegen, passen Sie Datenformate für den Partner-Einsatz an und verfolgen Sie die Nutzung für die Kostenzuordnung.
Daten sicher teilen
Teilen Sie Kafka-Daten mit externen Partnern, ohne Ihre Infrastruktur übermäßig offenzulegen, passen Sie Datenformate ohne Dual-Write-Muster an und verfolgen Sie die Nutzung für die Abrechnung.
- Virtuelle Partner-Cluster – Bereitstellung isolierter virtueller Cluster mit Topic-Mappings, Ratenbegrenzungen und Service-Accounts für Dritte
- Partner-Topic-Views – Erstellung logischer Topic-Views mit Aliasing für partnerspezifischen Zugriff ohne Infrastrukturduplizierung
- Datenformattransformationen – Transformation von Nachrichtenformaten mithilfe von SQL-Ausdrücken für partnerspezifische Schemas
- Partner-Chargeback – Verfolgung von Verbrauchsmetriken nach Partner zur Nutzungszuordnung und Kostenzuteilung

apiVersion: gateway/v2
kind: VirtualCluster
metadata:
name: partner-a
spec:
type: Partner
aclEnabled: true
superUsers:
- partner-admin
apiVersion: gateway/v2
kind: GatewayServiceAccount
metadata:
name: partner-admin
vCluster: partner-a
spec:
type: LOCAL
apiVersion: gateway/v2
kind: AliasTopic
metadata:
name: orders
vCluster: partner-a
spec:
physicalName: internal-ordersKafka-Proxy-Vergleich
Wie schneidet Conduktor Gateway ab?
Vergleichen Sie Conduktor Gateway mit dem Wettbewerb – Funktion für Funktion.
Confluent Gateway Kong Gravitee Aklivity Zilla Kroxylicious
Messbarer Nutzen
Echte Ergebnisse von Platform-Teams, die Gateway einsetzen.
Eine europäische Fluggesellschaft wechselte in 9 Monaten zu Confluent Cloud – ohne Ausfallzeit.
Ein Zahlungsdienstleister erhielt die MasterCard- und VISA-Zertifizierung mit Gateway-Verschlüsselung.
FlixBus skalierte Multi-Tenancy ohne Infrastrukturvervielfachung.
Verschlüsselung, Routing und Richtlinien werden auf Proxy-Ebene angewendet – nicht in Anwendungen.
Weitere Kundenberichte lesen
Bereit, Gateway auszuprobieren?
Erfahren Sie, wie Platform-Teams unseren Kafka-Proxy nutzen, um Verschlüsselung, Multi-Tenancy und Traffic-Steuerung hinzuzufügen – ohne den Anwendungscode zu ändern.