Schema Registry Proxy
Autoriser. Auditer. Gouverner.
Un proxy qui comprend le schema registry et ajoute contrôle d'accès, audit et application des politiques au registry que vous exploitez déjà. Pointez vos clients dessus. Aucune modification de code.
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.
Il parle schéma, pas seulement HTTP
La solution habituelle consiste à placer nginx ou une API gateway devant le registry. Raisonnable, mais cela protège des routes et des méthodes, pas des subjects. Impossible de distinguer une nouvelle version d'un écrasement destructeur, puisqu'un subject ou un schéma ne veut rien dire pour elle.
Le proxy parle l'API du schema registry lui-même. Il raisonne en subjects, versions et compatibilité : chaque règle s'exprime dans les termes du registry.
Autorisation prête à l'emploi
Les registries open source offrent des rôles grossiers ou un fichier de mots de passe, et aucun contrôle par subject. La réponse de Confluent, c'est le RBAC de Confluent Platform, souvent plus de 100 000 $ par an. Dans les deux cas, quiconque a un accès peut modifier n'importe quel schéma, et 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à. Et elles viennent de là où elles résident déjà : vos ACLs Kafka ou la propriété fédérée dans Console. 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.
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.
Un schéma est un livrable, pas un accident d'exécution
La plupart des incidents de schéma commencent de la même façon : le schéma naît comme effet de bord du premier message qu'un service envoie. Livrez-le délibérément et les erreurs se déplacent vers la revue de code, là où elles coûtent peu.
Enregistrez-le délibérément
Le serializer Confluent enregistre un schéma dès la première production : auto.register.schemas est activé par défaut. L'enregistrement se produit dès que ce chemin de code s'exécute pour la première fois, souvent des heures après le déploiement, ce qui rend une casse difficile à relier à sa cause. Provisionnez les schémas avant le déploiement et le registry les valide avant que quoi que ce soit ne parte.
Un historique de compatibilité par environnement
Dev accumule plus de versions que la QA, la QA plus que la prod. Chacun a sa propre lignée de compatibilité : un changement qui passe en dev peut malgré tout être rejeté face à la prod. Vérifiez-le par rapport à l'environnement dans lequel vous promouvez, et dev vous prévient avant que vous y arriviez.
Les schémas comme du code
Gardez vos subjects dans le gestionnaire de versions, relisez-les en pull request, appliquez-les depuis la CI. Le manifeste que lit le proxy est un fichier de votre dépôt : faire évoluer un schéma devient un diff que quelqu'un approuve, pas un appel qu'une application passe à l'exécution.
Conçu pour s'intégrer à votre stack. Compatible avec tout registry implémentant l'API Confluent Schema Registry, y compris Confluent Cloud, Apicurio et Karapace.
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 quoi que ce soit 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 vos standards de schémas une seule fois : niveaux de compatibilité minimaux, exigences de format, conventions de nommage et de namespace, documentation obligatoire, 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 | ✓ OIDC / OAuth2, les mêmes comptes que votre Kafka |
| Compatible avec | Tout registry | Tout registry | Confluent Platform uniquement | ✓ Tout registry exposant l'API Confluent SR |
| 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.
Passer au RBAC n'est pas une option de configuration. Les autorisations par topic que vos équipes ont accumulées doivent être remodelées en role bindings et réécrites sur chaque cluster et chaque environnement, en plus de la licence de plateforme : un programme de changement à part entière.
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.
Que peuvent faire les applications à travers le proxy ?
Seulement ce dont elles ont besoin : produire et consommer sur des schémas qui existent déjà. L'évolution, c'est-à-dire les nouvelles versions, les changements de compatibilité et les suppressions, passe par un workflow gouverné comme Console : les endpoints destructifs et de configuration ne sont jamais sur le chemin qu'emprunte une application. Et une fois l'enregistrement à l'exécution désactivé, un client ne peut plus enregistrer un schéma la première fois qu'il produit, des heures après le déploiement, là où l'auto-registration fait mal d'habitude.
Pourquoi tenir les suppressions et les changements de compatibilité à l'écart des applications ?
Parce que les deux sont quasiment irréversibles. Supprimez un subject ou une version et chaque message encore sérialisé avec lui devient illisible : vous perdez la capacité de désérialiser votre propre historique, exactement comme perdre une clé rend des données chiffrées irrécupérables. Assouplir le mode de compatibilité d'un subject est plus discret mais tout aussi destructeur : la prochaine version incompatible passe sans erreur sur le moment, et la garantie sur laquelle comptait chaque consommateur a disparu. Ce sont des actes délibérés et autorisés, pas quelque chose qu'une application ou une UI égarée devrait pouvoir déclencher.
Pourquoi ne pas simplement utiliser l'autorisation native du schema registry ?
Deux options natives existent, et les deux déçoivent. La première déduit les permissions de Kafka : celui qui peut écrire dans un topic peut écrire son subject, ce que donnait le Topic ACL Authorizer, désormais déprécié dans Confluent Platform 8.0. La seconde est une API de permissions native, mais presque aucun outillage de l'écosystème ne s'est construit autour : pas de Terraform, pas d'Ansible, pas de wrappers, donc peu d'équipes l'ont adoptée. Reste le RBAC Confluent et la licence de plateforme complète. Le proxy vous donne une autorisation par subject sur n'importe quel registry, avec les identités Kafka que vous avez déjà, sans ce compromis.
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é.