Conduktor Gateway
Routez. Protégez. Transformez.
Un proxy Kafka qui donne aux équipes platform les contrôles qu'elles ont toujours voulu, sans demander aux développeurs de modifier une seule ligne de code.

Augmentez votre infrastructure.
Kafka est puissant, mais il n'a pas été conçu pour la gouvernance, la sécurité ou l'application de politiques. Un Kafka Gateway comble ce manque, afin que les équipes platform puissent adapter Kafka à leurs besoins, et non l'inverse.
Pour les équipes platform Faites évoluer Kafka à l'échelle de vos équipes sans multiplier l'infrastructure ni la complexité.
Pour la sécurité & la conformité Appliquez le chiffrement et les politiques de données au niveau de l'infrastructure, pas dans le code applicatif.
Qu'est-ce que Conduktor Gateway ?
Conduktor Gateway est un proxy Kafka qui se place entre vos applications clientes et vos brokers Kafka. Il offre aux équipes platform un point de contrôle unique pour la sécurité, le routage, la qualité des données et la multi-tenancy, sans modifier le code applicatif.
Protocole Kafka natif
Gateway implémente le protocole wire Kafka. Les clients s'y connectent exactement comme à un broker. Il suffit de mettre à jour bootstrap.servers et le proxy gère l'authentification, le chiffrement, le routage et l'observabilité de manière transparente.
Contrôle au niveau de l'infrastructure
Ajoutez des fonctionnalités non disponibles nativement — chiffrement au niveau des champs, clusters virtuels, vues de topics basées sur SQL, tests de chaos — sans demander à chaque équipe applicative de les implémenter individuellement.
Aucune modification des applications
Chaque requête de production et de consommation transite par le proxy. Les politiques s'appliquent au niveau de l'infrastructure, ce qui permet aux équipes platform d'imposer des standards à toutes les équipes depuis un seul endroit.
Vous avez simplement besoin d'atteindre Kafka à travers des réseaux ? Essayez Gateway Community Edition, notre proxy Kafka gratuit. Il connecte les clients à des clusters situés dans d'autres VPC, clouds ou réseaux privés, sans modification de vos brokers ou de vos credentials.
Cas d'usage de Gateway
Routage, multi-tenancy & performance
Éliminez les barrières réseau, délivrez des environnements Kafka isolés sans clusters séparés et optimisez le débit au niveau du proxy.
Connectez-vous sans modifier le code
Supprimez les barrières réseau à la connectivité Kafka grâce au routage par proxy, centralisez l'authentification via l'intégration OIDC et appliquez un contrôle d'accès granulaire au-delà de ce que les ACLs natifs permettent.
- Connectivité inter-réseaux : routage des connexions clientes via Gateway sans modification de configuration côté client
- Authentification centralisée : intégration avec des systèmes OIDC externes pour un contrôle d'accès unifié sur les déploiements hybrides
- Pistes d'audit applicatives : traçabilité de chaque action sur les ressources Kafka pour répondre aux exigences SOC2, ISO 27001 et GDPR
# 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"
}Découpler les tenants des clusters
Délivrez des environnements Kafka isolés à plusieurs équipes sans le coût de clusters séparés, éliminez le chaos dans les noms de topics et réduisez drastiquement le nombre de partitions.
- Clusters virtuels : déploiement de plusieurs clusters Kafka logiques sur un seul cluster physique avec des namespaces isolés et des périmètres ACL
- Concentration de topics : consolidation des topics à faible volume en topics physiques partagés, réduisant le nombre de partitions de 90 % ou plus
- Alias de topics : accès aux topics via des noms aliasés pour les renommer sans modifier les clients ou masquer la nomenclature interne
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-ordersGérez la charge efficacement
Réduisez la charge des brokers liée aux lectures répétitives, gérez les payloads surdimensionnés sans impacter les performances du cluster et fournissez des vues filtrées de topics sans la complexité du stream processing.
- SQL topics : création de topics virtuels en lecture seule avec filtrage et projections basés sur SQL au niveau du gateway
- Cache : distribution des messages fréquemment accédés depuis le cache Gateway pour réduire la charge des brokers lors de lectures à haute fréquence
- Déchargement des messages volumineux : déchargement automatique des messages dépassant les seuils de taille vers S3 ou 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-1Gouvernez votre schema registry
Ajoutez authentification, contrôle d'accès et observabilité à votre schema registry grâce à un proxy Kafka transparent qui applique la gouvernance sur chaque opération.
- Authentification JWT/OIDC : validation des tokens de votre fournisseur d'identité existant avant qu'aucune requête n'atteigne le registry
- Contrôles d'accès par subject : application des permissions en lecture et écriture avec correspondance exacte, wildcard et préfixe
- Observabilité complète : traçage de chaque opération avec OpenTelemetry, métriques avec Prometheus et journalisation en JSON structuré
# 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/OTLPRésilience & reprise après sinistre
Empêchez les mauvaises configurations des développeurs de déstabiliser votre platform, maintenez la continuité opérationnelle lors des incidents et validez la tolérance aux pannes via des tests contrôlés.
Évitez les mauvaises configurations
Éliminez les problèmes de voisin bruyant et la dérive de configuration grâce aux protections du Kafka Gateway, qui appliquent les conventions de nommage, les limites de rétention, les quotas et les règles de réplication avant que les incidents n'atteignent la production.
- Politiques de configuration : application des conventions de nommage des topics, des limites de rétention, des règles de réplication et des exigences de schéma au provisionnement et à l'exécution
- Contrôle du trafic & quotas : application de limites de bande passante et de débit par tenant ou cluster pour prévenir les effets de voisinage
- Politiques producteur & consommateur : garantie des exigences d'acquittement, de compression et d'idempotence sur tous les producteurs, et contrôle du comportement de fetch sur les consommateurs
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: 52428800Migrez et récupérez en toute confiance
Maintenez la continuité opérationnelle lors des migrations de clusters et du failover grâce à la redirection transparente par proxy Kafka, et validez la tolérance aux pannes via des tests de chaos contrôlés.
- Bascule de cluster & failover : migration des applications entre clusters ou bascule vers l'infrastructure de failover sans modification de configuration applicative ni coordination entre équipes
- Chaos engineering : injection de latence, d'erreurs de protocole et de corruption de messages via les interceptors Gateway pour tester la résilience sans perturber la production
# 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_MESSAGEProtection des données
Contrôlez les métadonnées des messages, appliquez la qualité des données, protégez les champs sensibles et vérifiez l'intégrité des messages au niveau du proxy.
Bloquez les données incorrectes à la source
Bloquez les données malformées et non conformes à la source plutôt que de découvrir les problèmes de qualité après qu'ils ont impacté les systèmes en aval.
- Détection de la qualité des données : évaluation des données transitant par Gateway pour vérifier leur conformité aux règles de validation et aux standards de qualité
- Application de la qualité des données : blocage, redirection ou marquage des messages qui enfreignent les règles de qualité avant qu'ils n'atteignent Kafka
{
"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
}
}
Chiffrez de manière cohérente sur toutes les applications
Garantissez un chiffrement cohérent sur toutes les applications grâce à l'application centralisée du KMS au niveau du Kafka Gateway, et activez l'analyse des données sensibles via la tokenisation au niveau des champs.
- Chiffrement centralisé : application du chiffrement via une connexion KMS standardisée pour prévenir la dérive de configuration et activer le crypto-shredding pour la conformité GDPR
- Intégration KMS multi-cloud : connexion avec Vault, AWS KMS, Azure Key Vault, GCP KMS ou Fortanix pour la conformité PCI-DSS, HIPAA et GDPR
- Chiffrement au niveau des champs : chiffrement des champs sensibles avec ciblage basé sur le schéma tout en conservant les données non sensibles lisibles
- Tokenisation : remplacement des valeurs sensibles par des tokens tout en préservant le format pour les analyses
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}Vérifiez l'intégrité des messages
Vérifiez l'authenticité des messages et détectez les altérations pour répondre aux exigences d'audit et de chaîne de traçabilité.
- Signature cryptographique : signature des messages au niveau du gateway pour détecter les altérations et vérifier l'origine des messages à des fins de conformité
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}Contrôlez les métadonnées des messages
Garantissez que les métadonnées des messages sont conformes aux standards de l'entreprise sans nécessiter de modifications applicatives.
- Gestion des headers & messages : injection, modification ou suppression des headers de messages pour transformer et contrôler les métadonnées de manière centralisée
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-.*"Partage de données externe
Partagez des données Kafka avec des partenaires externes sans surexposer votre infrastructure, adaptez les formats de données pour la consommation partenaire et suivez l'utilisation pour l'allocation des coûts.
Partagez les données en toute sécurité
Partagez des données Kafka avec des partenaires externes sans surexposer votre infrastructure, adaptez les formats de données sans pattern de double écriture et suivez l'utilisation pour la facturation.
- Clusters virtuels partenaires : provisionnement de clusters virtuels isolés avec mappings de topics, limites de débit et service accounts pour les tiers
- Vues de topics partenaires : création de vues logiques de topics avec aliasing pour un accès spécifique aux partenaires sans dupliquer l'infrastructure
- Transformations de format de données : transformation des formats de messages via des expressions SQL pour des schémas spécifiques aux partenaires
- Refacturation partenaire : suivi des métriques de consommation par partenaire pour l'attribution d'usage et l'allocation des coûts

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-ordersComparaison des proxys Kafka
Comment Conduktor Gateway se positionne-t-il ?
Comparez Conduktor Gateway à la concurrence, fonctionnalité par fonctionnalité.
Confluent Gateway Kong Gravitee Aklivity Zilla Kroxylicious
Impact mesurable
Des résultats concrets des équipes platform utilisant Gateway.
Une compagnie aérienne européenne a migré vers Confluent Cloud en 9 mois sans interruption de service.
Un processeur de paiement a obtenu la certification MasterCard et VISA grâce au chiffrement Gateway.
FlixBus a mis à l'échelle la multi-tenancy sans multiplier l'infrastructure.
Chiffrement, routage et politiques appliqués au niveau du proxy, et non dans les applications.
Lire d'autres témoignages clients
Prêt à essayer Gateway ?
Découvrez comment les équipes platform utilisent notre proxy Kafka pour ajouter chiffrement, multi-tenancy et contrôle du trafic sans modifier le code applicatif.