Kafka self-service — topic requests and governed access

Conduktor Self-service lets application teams request Kafka topics and access without going through the platform team for every change. Platform teams set the rules upfront; everything else flows from there.

​

How it works

Self-service introduces two roles:

• Platform teams — assign application’s owner a set of resources and define the governance rules they will be restricted by.
• Application teams — create resources within their ownership scope, approve access requests, and subscribe to other teams’ topics. Approved requests are applied automatically without platform team intervention for each change.

Topic creation is a direct API call that passes if the request is policy-compliant — no approval workflow needed. Access requests between teams go through the owning application team, not the platform team: Every change goes into Git. You get a full history and can review anything before it lands on Kafka.

​

Key concepts

​

Benefits

• Less bottleneck — teams don’t wait on platform for routine requests
• Guardrails, not gatekeeping — policies constrain what can be requested, not who can work
• Full audit trail — every change is in Git, reviewable and revertible
• Explicit ownership — each resource has a declared owner, so access requests go to the right person
• Data discovery — Kafka is made to open access to data. Our data catalog is here for that and exposes topics metadata to add context

​

Related resources

• Use Self-service
• Check out the quick start tutorial
• Start from the Self-service reference template — a production-ready GitHub repository layout with CODEOWNERS, scope-based CI/CD workflows, and example ResourcePolicies
• View resource reference
• Give us feedback/request a feature