[
https://issues.apache.org/jira/browse/KAFKA-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859992#comment-17859992
]
Greg Harris commented on KAFKA-16707:
-------------------------------------
Hi [~handfreezer] Thank you for clarifying that this is a new feature for the
built-in StandardAuthorizer.
This would still require a KIP to discuss the design and expected behavior. I
don't have any comments about the design itself as I don't use this part of
Kafka, but a KIP will get you that feedback.
> (Also, as I didn't remember reference of other Principal Type than User in
> the Kafka doc, may I ask you to point me where in the doc (and code) there
> are checks on Principal Type of other value than User?)
Here the KafkaPrincipal mentions that the only default type is User:
[https://github.com/apache/kafka/blob/f995edccad5d964c0d57028d5a3872ca24f75825/clients/src/main/java/org/apache/kafka/common/security/auth/KafkaPrincipal.java#L24-L26]
And here's one example of using the USER_TYPE constant:
[https://github.com/apache/kafka/blob/ceec218351ff741dc338edf8d3810c1f36555e33/core/src/main/scala/kafka/server/KafkaApis.scala#L3154]
These might not be very relevant or pose any restrictions for someone
implementing new PrincipalTypes in a custom Authorizer, and so they may also
not be an issue for this new feature.
> Kafka Kraft : adding Principal Type in StandardACL for matching with
> KafkaPrincipal of connected client in order to defined ACL with a notion of
> group
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-16707
> URL: https://issues.apache.org/jira/browse/KAFKA-16707
> Project: Kafka
> Issue Type: Improvement
> Components: kraft, security
> Affects Versions: 3.7.0, 3.8.0, 3.7.1
> Reporter: Franck LEDAY
> Assignee: Franck LEDAY
> Priority: Major
> Labels: KafkaPrincipal, acl, authorization, group, metadata,
> security, user
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Default StandardAuthorizer in Kraft mode is defining a KafkaPrincpal as
> type=User and a name, and a special wildcard eventually.
> The difficulty with this solution is that we can't define ACL by group of
> KafkaPrincipal.
> There is a way for the moment to do so by defining RULE to rewrite the
> KafkaPrincipal name field, BUT, to introduce this way the notion of group,
> you have to set rules which will make you loose the uniq part of the
> KafkaPrincipal name of the connected client.
> The concept here, in the StandardAuthorizer of Kafka Kraft, is to add the
> management of KafkaPrincipal type:
> * Regex
> * StartsWith
> * EndsWith
> * Contains
> * (User is still available and keep working as before to avoid any
> regression/issue with current configurations)
> This would be done in the StandardAcl class of metadata/authorizer, and the
> findresult method of StandardAuthorizerData will delegate the match to the
> StandardAcl class (for performance reason, see below explanation).
> By this way, you can still use RULEs to rewrite KafkaPrincipal name of
> connected client (say you want to transform a DN of SSL certificate :
> cn=myCN,ou=myOU,c=FR becomes myCN@myOU), and then, you can define a new ACL
> with principal like: 'Regex:^.*@my[oO]U$' that will match all connected
> client with a certificate bind to ou=myOU . Note in this particular case, the
> same can be done with 'EndsWtih:@myOU', and the type 'Contains' can work, but
> I imagine more the usage of this type for matching in a multigroup definition
> in a KafkaPrincipal.
>
> Note about performance reason : for the moment, I have it implemented in a
> fork of StandardAuthroizer/StandardAuthroizerData/StandardAcl defined by the
> property authorizer.class.name in a cluster of Kraft with SSL authentication
> required and tested fine. But, by this way, every time that an ACL is checked
> against a KafkaPrincipal, I do a strcmp of the KafkaPrincipal type of the ACL
> to determine the matching method to be done. By implementing it in
> StandardAcl class, and then delegating the matching from
> StandardAuthorizerData to the StandardAcl class, this allow to analyse and
> store the type of the KafkaPrincipal method for matching as an enum, and the
> KafkaPrincipal name separately in order to avoid redoing the job each time a
> match has to be checked.
>
> Here is my status of the implementation:
> * I have this solution ('performance reason') implemented in fork (then
> branch) of the 3.7.0 github repo,
> * I added few unit test, and a gradlew metadata:test is working fine on all
> tests except one (witch is failing also on branch 3.7.0 without my changes),
> * I added few lines about in security.html .
>
> I'm opening the issue to discuss it with you, because I would like to create
> a PR on Github for next version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
