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.
Key concepts
| Concept | Description |
|---|---|
| Application | A logical grouping for a team or service — owns its topics and ACLs |
| Application team | Group of people not owning the application’s topics, but interacting with them, and that should inherit from the same permissions (e.g., support team) |
| Access request | A request for read or write access to a topic owned by another application |
| Policy | Rules that constrain what teams can request (e.g., max partitions, naming conventions) |
| Ownership | Each resource has a declared owner; access requests go through that owner for approval |
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