[
https://issues.apache.org/jira/browse/RANGER-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Katona updated RANGER-3809:
----------------------------------
Description:
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.
was:
In Kafka 2.8 this new authorization method was introduced mainly to ease
authorization (setup) of idempotent producers.
The default implementation of 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
{code}
/**
* Returns ACL bindings which match the provided filter.
* <p>
* This is a synchronous API designed for use with locally cached ACLs.
This method is invoked on the request
* thread while processing DescribeAcls requests and should avoid
time-consuming remote communication that may
* block request threads.
*
* @return Iterator for ACL bindings, which may be populated lazily.
*/
Iterable<AclBinding> acls(AclBindingFilter filter);
{code}
{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.
> 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
> 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)
