[ 
https://issues.apache.org/jira/browse/KAFKA-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashish K Singh updated KAFKA-3186:
----------------------------------
    Description: 
[KIP-50|https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Move+Authorizer+to+a+separate+package]
 has more details.

Kafka supports pluggable authorization. Third party authorizer implementations 
allow existing authorization systems like, Apache Sentry, Apache Ranger, etc to 
extend authorization to Kafka as well. Implementing Kafka's authorizer 
interface requires depending on kafka's core, which is huge. This has been 
already raised as a concern by Sentry, Ranger and Kafka community. Even Kafka 
clients require duplication of authorization related classes, like Resource, 
Operation, etc, for adding ACLs CRUD APIs.

Kafka authorizer is agnostic of principal types it supports, so are the acls 
CRUD methods in Authorizer interface. The intent behind is to keep Kafka 
principal types pluggable, which is really great. However, this leads to Acls 
CRUD methods not performing any check on validity of acls, as they are not 
aware of what principal types Authorizer implementation supports. This opens up 
space for lots of user errors, KAFKA-3097 is an instance.

  was:
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.


> KIP-50: Move Authorizer and related classes to separate package.
> ----------------------------------------------------------------
>
>                 Key: KAFKA-3186
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3186
>             Project: Kafka
>          Issue Type: Improvement
>    Affects Versions: 0.9.0.0
>            Reporter: Ashish K Singh
>            Assignee: Ashish K Singh
>             Fix For: 0.10.1.0
>
>
> [KIP-50|https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Move+Authorizer+to+a+separate+package]
>  has more details.
> Kafka supports pluggable authorization. Third party authorizer 
> implementations allow existing authorization systems like, Apache Sentry, 
> Apache Ranger, etc to extend authorization to Kafka as well. Implementing 
> Kafka's authorizer interface requires depending on kafka's core, which is 
> huge. This has been already raised as a concern by Sentry, Ranger and Kafka 
> community. Even Kafka clients require duplication of authorization related 
> classes, like Resource, Operation, etc, for adding ACLs CRUD APIs.
> Kafka authorizer is agnostic of principal types it supports, so are the acls 
> CRUD methods in Authorizer interface. The intent behind is to keep Kafka 
> principal types pluggable, which is really great. However, this leads to Acls 
> CRUD methods not performing any check on validity of acls, as they are not 
> aware of what principal types Authorizer implementation supports. This opens 
> up space for lots of user errors, KAFKA-3097 is an instance.



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

Reply via email to