[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872611#comment-17872611
]
Madhan Neethiraj commented on RANGER-3809:
------------------------------------------
[~rmani] - can you please review and resolve this Jira if there are no more
pending tasks?
> Implement authorizeByResourceType method of Kafka Authorizer
> ------------------------------------------------------------
>
> Key: RANGER-3809
> URL: https://issues.apache.org/jira/browse/RANGER-3809
> Project: Ranger
> Issue Type: Improvement
> Components: plugins
> Affects Versions: 3.0.0
> Reporter: Andras Katona
> Assignee: Ramesh Mani
> Priority: Major
> Fix For: 3.0.0, 2.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Kafka 2.8 this new authorization method was introduced mainly to ease
> authorization (setup) of idempotent producers.
> The default implementation of {{authorizeByResourceType}} uses
> [acls()|https://github.com/apache/kafka/blob/a3c7017ff7e543b50f84110195690a253f19d9cf/clients/src/main/java/org/apache/kafka/server/authorizer/Authorizer.java#L154]
> which is [not
> implemented|https://github.com/apache/ranger/blob/fc7ad98fbb2ee7bb7d4cd3329abc438a73e0444a/plugin-kafka/src/main/java/org/apache/ranger/authorization/kafka/authorizer/RangerKafkaAuthorizer.java#L332-L335]
> in Kafka Ranger Plugin, but it is not really efficient and it is recommended
> to implement/override it in custom authorizer implementation (meaning Ranger
> in our case).
> {code}
> /**
> * Check if the caller is authorized to perform the given ACL operation
> on at least one
> * resource of the given type.
> *
> * Custom authorizer implementations should consider overriding this
> default implementation because:
> * 1. The default implementation iterates all AclBindings multiple times,
> without any caching
> * by principal, host, operation, permission types, and resource
> types. More efficient
> * implementations may be added in custom authorizers that directly
> access cached entries.
> * 2. The default implementation cannot integrate with any audit logging
> included in the
> * authorizer implementation.
> * 3. The default implementation does not support any custom authorizer
> configs or other access
> * rules apart from ACLs.
> *
> * @param requestContext Request context including request resourceType,
> security protocol and listener name
> * @param op The ACL operation to check
> * @param resourceType The resource type to check
> * @return Return {@link AuthorizationResult#ALLOWED} if
> the caller is authorized
> * to perform the given ACL operation on at least
> one resource of the
> * given type. Return {@link
> AuthorizationResult#DENIED} otherwise.
> */
> default AuthorizationResult
> authorizeByResourceType(AuthorizableRequestContext requestContext,
> AclOperation op, ResourceType resourceType) {
> {code}
> In Kafka 3.0.1, 3.1.1 and 3.2.0, producers are idempotent by default
> (KAFKA-13598) and the authorization of producer initialization fails, in case
> the user doesn't have the deprecated idempotent_write access, as it will call
> the {{authorizeByResourceType}} and that calls {{acls}}.
> {code}
> public Iterable<AclBinding> acls(AclBindingFilter filter) {
> logger.error("(getting) acls is not supported by Ranger for Kafka");
> throw new UnsupportedOperationException("(getting) acls is not supported
> by Ranger for Kafka");
> }
> {code}
> With [this
> commit|https://github.com/apache/ranger/commit/0ec279474e0439f6c5e7d4497db191fb7cc99bc1]
> {{authorizeByResourceType}} got an implementation with a basic validation
> check and a (constant) denial response. It's just making
> UnsupportedOperationException disappear and having an expected response for
> initProducer authorization.
> Until the proper implementation is done, the idempotent_write access should
> be granted for the producer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
