-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Allow domain services to create arbitrary private topics. (#63)
* Allow domain services to create arbitrary private topics. fixes: #61
- Loading branch information
1 parent
0f6b98e
commit d658132
Showing
4 changed files
with
170 additions
and
86 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
# Kafka SpecMesh extension | ||
|
||
Extends SpecMesh with the concept of public, protected and public topics. | ||
|
||
## Topic structure | ||
|
||
Topic names in the spec come under the `channel` section. Their names either: | ||
|
||
* start with `_public`, `_protected` or `_private` for topics _owned_ by the domain, or | ||
* are the fully qualified topic name of some other (domain's) topic. | ||
|
||
For topic's owned by the domain, their full topic name is that used in the spec, prefixed with the spec's domain id, | ||
i.e. `<domain-id>.<channel-name>`. In this way, all topics owned by the domain and also prefixed by the domain name, | ||
making it trivial to trace back the topic name to its owning domain. | ||
|
||
## Authorisation | ||
|
||
## Topic authorisation | ||
|
||
The provisioner will set ACLs to enforce the following topic authorisation: | ||
|
||
### Public topics: | ||
|
||
Only the domain itself can `WRITE` to public topics; Any domain can `READ` from them. | ||
|
||
### Protected topics: | ||
|
||
Only the domain itself can `WRITE` to protected topics; Any domain specifically tagged in the spec can `READ` from them. | ||
|
||
Access to a protected topic can be granted to another domain by adding a `grant-access:` tag to the topic: | ||
|
||
```yaml | ||
tags: [ | ||
name: "grant-access:some.other.domain" | ||
] | ||
``` | ||
|
||
### Private topics: | ||
|
||
Only the domain itself can `WRITE` to private topics; Only the domain itself can `READ` to private topics. | ||
|
||
Additionally, the domain itself also has `CREATE` permissions for topics under its domain id. | ||
This allows the domain's services to create any additional internal topics required, e.g. Kafka Streams | ||
library creates repartition and changelog topics for stores automatically using the Admin client. | ||
|
||
As services are free to make additional private topics, provisioning does _not_ remove existing private topics not in the spec. | ||
This places the responsibility of cleaning up private topics on engineering teams. However, as these are private | ||
topics, it is easy to determine if such topics are or are not actively in use by the domain's services. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters