You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ranger.apache.org by "Ramesh Mani (Jira)" <ji...@apache.org> on 2023/06/06 18:40:00 UTC
[jira] [Updated] (RANGER-3809) Implement authorizeByResourceType method of Kafka Authorizer
[ https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramesh Mani updated RANGER-3809:
--------------------------------
Fix Version/s: 3.0.0
> 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
>
> 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)