[ 
https://issues.apache.org/jira/browse/KAFKA-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15127632#comment-15127632
 ] 

Gwen Shapira commented on KAFKA-3186:
-------------------------------------

I assume you are referring to the fact that Sentry also manages Groups and 
Roles, so a Principal may be a group?

Is this specifically for the CLI, or are there other areas that are a problem? 
I'm asking because unlike the authorizer API which is pluggable, the CLI is 
specific to the defaultAuthorizer. We are assuming that Sentry and Ranger users 
will use whatever GUI / CLI is provided by Sentry and Ranger. Does that make 
sense? Or are you talking about something else entirely?

> Kafka authorizer should be aware of principal types it supports.
> ----------------------------------------------------------------
>
>                 Key: KAFKA-3186
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3186
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Ashish K Singh
>            Assignee: Ashish K Singh
>
> Currently, Kafka authorizer is agnostic of principal types it supports, so 
> are the acls CRUD methods in {{kafka.security.auth.Authorizer}}. The intent 
> behind is to keep Kafka authorization pluggable, which is really great. 
> However, this leads to following issues.
> 1. {{kafka-acls.sh}} supports pluggable authorizer and custom principals, 
> however is some what integrated with {{SimpleAclsAuthorizer}}. The help 
> messages has details which might not be true for a custom authorizer. For 
> instance, assuming User is a supported PrincipalType.
> 2. Acls CRUD methods perform no check on validity of acls, as they are not 
> aware of what principal types the support. This opens up space for lots of 
> user errors, KAFKA-3097 is an instance.
> I suggest we add a {{getSupportedPrincipalTypes}} method to authorizer and 
> use that for acls verification during acls CRUD, and make {{kafka-acls.sh}} 
> help messages more generic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to