-
-
Notifications
You must be signed in to change notification settings - Fork 9
011 - user namespace filter #80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,69 @@ | ||
| <!-- This template is provided as an example with sections you may wish to comment on with respect to your proposal. Add or remove sections as required to best articulate the proposal. --> | ||
|
|
||
| # User Namespace Filter | ||
|
|
||
| Proposes the introduction of a "User Namespace Filter" to Kroxylicious's core filters. | ||
|
|
||
| The role of the User Namespace Filter is to give the client a private space within the kafka cluster space that is isolated from other users sharing the cluster. Namespacing can be applied selectively to different resource types. This allows | ||
| the possibility for some resource types (probably topics) to be shared between users whereas only resource instances exist in the private space. | ||
|
|
||
| ## Current situation | ||
|
|
||
| The project has a preview multi-tenancy filter, which is a similar idea to this one except that it applies unconditionally to all resource types. | ||
|
|
||
| ## Motivation | ||
|
|
||
| We encountered a use-case where the desire was to share topics but maintain isolated spaces for groups and transactional-ids. | ||
|
|
||
| ## Proposal | ||
|
|
||
| The role of the user namespace filter is to give the client the impression of a private kafka cluster space that is isolated from other clients sharing the cluster. Namespacing can be applied selectively to different resource types. | ||
|
|
||
| The filter will use a pluggable API to determine how to map the name of each resource. Operations that retrieve lists of resources will see only those that fall within the namespace. | ||
|
|
||
| For the initial release, the filter will need to support only namespacing for consumer group names and transactional ids. There will be scope for the filter to support prefixing of topic resources, but this won’t be supported in the initial release. | ||
|
|
||
| This proposal will deliver a simple implementation of the API that simply uses the principal as the prefix. | ||
| The principal will be added to the resource as it is sent to the server, and removed as it is returned in the response. | ||
|
|
||
| ### APIs | ||
|
|
||
| #### Filter Configuration | ||
|
|
||
| ```yaml | ||
| type: UserNamespaceFilter | ||
| config: | ||
| resourceNameMappers: | ||
| - resourceTypes: [TRANSACTIONAL_ID, GROUP_ID] | ||
| resourceNameMapper: SimplePrincipalPrefixingNameMapper | ||
| ``` | ||
|
|
||
| #### Resource Name Mapper API | ||
|
|
||
| Asynchronous interface that lets the filter map from downstream names to upstream names and vice-versa. It also | ||
| has the responsibility to filter the upstream view, removing resources that don't belong in the view. | ||
|
|
||
| ```java | ||
| interface ResourceNameMapper { | ||
| /** Return a mapping of downstream names to upstream names. */ | ||
| CompletionStage<Map<String, String>> mapDownstreamResourceNames(String authorizationId, ResourceType resourceType, List<String> downstreamResourceNames); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what would happen if there is no SASL transaction for a connection? Is authorizationId nullable? Or does the Filter not do any resource mapping if there is no authorizationId?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it only makes sense to use this filter when a filter has been established on the channel. |
||
| /** Return a filtered map of upstream resource names to downstream names. Any resources that do not form part of the view will be omitted from the map. */ | ||
| CompletionStage<Map<String, String>> mapUpstreamFilteredResourceNames(String authorizationId, ResourceType resourceType, List<String> upstreamResourceNames); | ||
| } | ||
| ``` | ||
|
|
||
| ## Affected/not affected projects | ||
|
|
||
| Call out the projects in the Kroxylicious organisation that are/are not affected by this proposal. | ||
|
|
||
| ## Compatibility | ||
|
|
||
| Call out any future or backwards compatibility considerations this proposal has accounted for. | ||
|
|
||
| ## Rejected alternatives | ||
|
|
||
| Call out options that were considered while creating this proposal, but then later rejected, along with reasons why. | ||
|
|
||
| ## Limitations | ||
|
|
||
| The name prefixing approach reduces the length of the name that the client may use for resource names. If the prefixed name exceeds the length permitted by Kafka the request must fail in an understandable way. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which Principal? Does it support SASL and TLS?
authorizationIdimplies it's SASL oriented, I think the proposal should talk about this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given #79 (comment), I think the mapper will accept the Subject and they'll be configuration saying what Principal type should be accessed from the Subject. If the Principal isn't present, it'll fail.