Schema Registry Proxy
Autoriser. Auditer. Gouverner.
Un proxy conçu pour Kafka qui ajoute contrôle d'accès, audit et application des politiques au schema registry que vous exploitez déjà. Aucune modification côté client.
Protégeons le schema registry comme nous protégeons Kafka.
Nous avons conçu le Schema Registry Proxy pour que chaque opération sur les schémas soit autorisée et tracée, sur le registry que vous exploitez déjà, avec les identités que vous gérez déjà. Déployez-le et pointez-le vers n'importe quel fournisseur.
Autorisation prête à l'emploi
Le Schema Registry gratuit de Confluent ne propose pas d'autorisation : toute personne ayant accès peut modifier n'importe quel schéma. La solution ? Confluent Platform, souvent à plus de 100 000 $ par an. Les options open source : des rôles grossiers ou des fichiers de mots de passe. Dans tous les cas, la charge vous incombe.
Des permissions de lecture et d'écriture par subject, vérifiées à chaque requête, sur le registry que vous exploitez déjà. Sans licence de plateforme.
Tracez chaque opération
Par défaut, l'audit du schema registry n'existe pas. Chez les éditeurs, c'est un niveau payant supplémentaire. Un schéma change, les consumers tombent, et il n'existe aucune trace de qui l'a fait, quand, ni pourquoi. La conformité réclame des preuves et vous n'en avez aucune à fournir.
Chaque opération est tracée de bout en bout, chaque refus est journalisé avec l'identité de l'auteur, et chaque modification de permission est enregistrée.
Héritez de vos permissions Kafka
La solution habituelle consiste à placer nginx ou une API gateway devant le registry. Raisonnable, mais cela protège des routes, pas des subjects. Impossible d'hériter des permissions déjà gérées dans Kafka ou Console, et l'intégration de votre fournisseur d'identité devient une configuration que quelqu'un doit maintenir indéfiniment.
Les permissions viennent de là où elles résident : vos ACLs Kafka ou la propriété fédérée dans Console. OIDC et rotation des clés intégrés.
Accorder · Appliquer · Observer.
Attribuez à chaque application ses subjects, laissez le proxy vérifier chaque appel et conservez une trace de tout. Les permissions proviennent de Console ou des ACLs Kafka que vous gérez déjà.
apiVersion: self-serve/v1
kind: ApplicationInstance
metadata:
application: "payments"
name: "payments-prod"
spec:
cluster: "prod-kafka"
serviceAccount: "payments-service"
resources:
- type: TOPIC
patternType: PREFIXED
name: "payments"
- type: SUBJECT
patternType: PREFIXED
name: "payments"
$ conduktor apply -f payments-prod.yaml
ApplicationInstance/payments-prod: Created$ kafka-acls --bootstrap-server kafka:9092 \
--command-config admin.properties \
--add --allow-principal User:payments-service \
--operation WRITE --operation READ \
--topic payments --resource-pattern-type PREFIXED
Adding ACLs for resource ResourcePattern(resourceType=TOPIC,
name=payments, patternType=PREFIXED):
(principal=User:payments-service, host=*,
operation=WRITE, permissionType=ALLOW)
(principal=User:payments-service, host=*,
operation=READ, permissionType=ALLOW)
# subjects inherit their topic's ACLs:
# subject payments-value → topic "payments"# payments-service registers a new version
$ curl -X POST http://srp:8080/subjects/payments-value/versions \
-H "Authorization: Bearer $PAYMENTS_TOKEN" \
-H "Content-Type: application/vnd.schemaregistry.v1+json" \
-d @new-schema.json
{"id": 7}
# analytics-service, never granted payments-*, tries the same
HTTP/1.1 403 Forbidden
{
"error_code": 403,
"message": "Forbidden: Service account
'analytics-service' is not authorized
to Write resource 'payments-value'"
}POST /subjects/{subject}/versions 38ms
│ http.method: POST
│ http.target: /subjects/payments-value/versions
│ http.status_code: 200
│
└─ HTTP POST schema-registry:8081 31ms
# one trace per operation: proxy overhead,
# backend latency, and status on every span{
"@timestamp": "2026-06-05T01:12:09.482Z",
"level": "WARN",
"service": "schema-registry-proxy",
"message": "Authorization failed: Service account
'analytics-service' is not authorized
to Write resource 'payments-value'"
}
{
"@timestamp": "2026-06-05T01:14:51.077Z",
"level": "WARN",
"service": "schema-registry-proxy",
"message": "Authentication failed: JWT validation
failed: Expired JWT"
}Le même registry, sécurisé.
Placez le proxy devant le schema registry que vous exploitez déjà.
Rien ne change pour vos applications. Tout change quant à qui peut modifier les schémas.
Avant Schema Registry Proxy
Certaines équipes laissent le registry totalement ouvert. La plupart le font précéder d'un proxy HTTP générique qui vérifie les routes et les tokens. Dans les deux cas, on protège la porte, pas les schémas derrière.
Après Schema Registry Proxy
Chaque requête est authentifiée auprès de votre fournisseur d'identité et vérifiée par rapport aux permissions par subject. Ajoutez Conduktor Console pour la propriété fédérée et la gestion humaine des schémas.
Conçu pour s'intégrer à votre stack. Compatible avec tout schema registry implémentant l'API Confluent, y compris Confluent Cloud.
Permissions par subject
Lecture et écriture par subject, avec correspondance exacte, par préfixe et par joker. Vérifiées à chaque requête, avant que rien n'atteigne votre registry.
Votre fournisseur d'identité
Keycloak, Auth0, Okta, Microsoft Entra ID, ou tout fournisseur OAuth2/OIDC disposant d'un endpoint JWKS. Rotation automatique des clés incluse.
Permissions natives Kafka
Distribuées via un topic Kafka depuis Console et appliquées en quelques secondes, ou lues depuis vos ACLs existantes. Sans redémarrage, sans nouveau datastore.
Échec sécurisé
Si une permission ne peut être vérifiée, la requête est refusée. Les erreurs et les timeouts ne conduisent jamais à un accès autorisé par défaut.
Traces, logs et métriques
Une trace OpenTelemetry par opération, chaque refus journalisé avec l'identité de l'appelant, et des métriques Prometheus prêtes à l'emploi.
S'exécute là où Kafka s'exécute
Un seul conteneur, on-premises, dans le cloud ou en environnement isolé. Aux côtés de Gateway ou de manière autonome.
Politiques de ressources · à venir
Définissez les standards de schémas une seule fois : niveaux de compatibilité minimaux, exigences de format et conventions de nommage, appliqués à l'enregistrement pour chaque équipe et chaque outil.
Limitation de débit · à venir
Limites de requêtes par principal, pour qu'un déploiement défaillant en boucle de redémarrage ne puisse pas saturer le registry dont dépendent toutes les autres équipes.
Quatre façons d'opérer un Schema Registry
La plupart des équipes se trouvent aujourd'hui dans l'une des trois premières colonnes.
| Aucune protection | Proxy HTTP générique | Confluent Platform RBAC | Schema Registry Proxy | |
|---|---|---|---|---|
| Autorisation | Aucune | Listes d'autorisation de routes | RBAC par subject | ✓ Par subject, préfixe et joker |
| Comprend | Rien | URLs et méthodes | Subjects | ✓ Les subjects et vos identités Kafka |
| Identité | Aucune | Configuration d'auth séparée | Plan d'identité Confluent | ✓ Les mêmes comptes que votre Kafka |
| Compatible avec | Tout registry | Tout registry | Confluent Platform uniquement | ✓ Tout registry compatible API Confluent |
| Licence | Gratuit | Temps d'ingénierie | Licence de plateforme complète | ✓ Autonome |
| Maintenance | Aucune | Votre équipe | Confluent | ✓ Conduktor |
Le Topic ACL Authorizer est déprécié. Pas vos ACLs.
Pendant des années, le Topic ACL Authorizer a permis aux propriétaires de topics de gouverner leurs propres subjects. Confluent Platform 8.0 le déprécie, ce qui place chaque équipe qui en dépend sur un calendrier de migration vers Confluent RBAC, une fonctionnalité sous licence enterprise.
Il existe une troisième option. Le mode autonome du proxy s'inspire de l'authorizer : les mêmes ACLs de topics continuent de gouverner les mêmes subjects. Pointez schema.registry.url vers le proxy et migrez selon votre propre calendrier. Sans migration RBAC, sans licence de plateforme.
Dois-je modifier le code de mon application ?
Non. Mettez à jour schema.registry.url dans la configuration de votre client Kafka pour pointer vers le proxy. Les producers et consumers continuent d'utiliser leurs serializers et deserializers existants. Aucune modification de code, aucun changement de bibliothèque.
Comment les permissions sont-elles gérées ?
De deux façons. Via Conduktor Console, où les subjects rejoignent votre modèle de propriété fédérée et les modifications s'appliquent en quelques secondes via Kafka. Ou en mode autonome, où le proxy lit les ACLs de topics Kafka que vous gérez déjà. Console n'est pas obligatoire.
Peut-il remplacer le Confluent Topic ACL Authorizer ?
Oui. Le mode autonome s'en inspire : les mêmes ACLs de topics gouvernent les mêmes subjects, avec la même sémantique. Il fonctionne sur Confluent Platform 8.0 et au-delà, où l'authorizer est déprécié. Le guide de déploiement couvre le mapping exact.
Quels schema registries le proxy prend-il en charge ?
Confluent Schema Registry et tout registry implémentant la même API REST, y compris Confluent Cloud.
Qu'en est-il des suppressions et des changements de compatibilité ?
Ils ne peuvent pas atteindre le registry via le proxy. Les applications n'accèdent qu'aux endpoints nécessaires pour produire et consommer, rien de destructif. La gestion des schémas s'effectue via Console, où elle est gouvernée et enregistrée.
Quel est le lien entre le Schema Registry Proxy et Conduktor Gateway ?
La même philosophie à une couche différente. Gateway se place devant vos clusters Kafka. Le Schema Registry Proxy se place devant votre registry. Les deux appliquent les droits d'accès sans toucher aux clients, et ils partagent les mêmes identités. Déployez-les ensemble ou séparément.
Prêt à gouverner votre schema registry ?
Notre équipe peut vous accompagner dans un déploiement adapté à votre fournisseur d'identité, votre configuration Kafka et vos exigences de conformité.