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.

Conduktor Gateway

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.

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.

Contrôle d'accès client & routage

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

En savoir plus →

Routage des clients
# 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"
}

Multi-tenancy & virtualisation

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

En savoir plus →

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
Concentrer les topics
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-orders

Performance & efficacité

Gé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

En savoir plus →

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:8081
apiVersion: 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: 60000
apiVersion: 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-1

Gouvernance du Schema Registry

Gouvernez 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é

En savoir plus →

# 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/OTLP

Ré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.

Résilience applicative

É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

En savoir plus →

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: 259200000
apiVersion: 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: 52428800

Reprise après sinistre & Failover

Migrez 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

En savoir plus →

# 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"}'
Basculer le trafic
# 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_MESSAGE

Protection 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.

Qualité des données

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

En savoir plus →

{
  "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
  }
}
Appliquer la qualité

Confidentialité des données

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

En savoir plus → · Chiffrement Kafka →

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}

Intégrité des données

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é

En savoir plus →

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ôle des métadonnées

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

En savoir plus →

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: true
apiVersion: 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.

Accès partenaire & partage de données

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

En savoir plus →

Suivre l'utilisation
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-orders

Comparaison 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

Comparer les proxys Kafka →

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.

Nous contacter