kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Henke <ghe...@cloudera.com>
Subject [DISCUSS] KIP-4 ACL Admin Schema
Date Thu, 14 Jul 2016 16:09:00 GMT
The KIP-4 Delete Topic Schema vote has passed and the patch
<https://github.com/apache/kafka/pull/1616> is available for review. Now I
would like to start the discussion for the Acls request/response and server
side implementations. This includes the ListAclsRequest/Response and the
AlterAclsRequest/Response.

Details for this implementation can be read here:
*https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-ACLAdminSchema(KAFKA-3266)
<https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-ACLAdminSchema(KAFKA-3266)>*

I have included the exact content below for clarity:

> ACL Admin Schema (KAFKA-3266
> <https://issues.apache.org/jira/browse/KAFKA-3266>)
>
> *Note*: Some of this work/code overlaps with "KIP-50 - Move Authorizer to
> o.a.k.common package
> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Move+Authorizer+to+o.a.k.common+package>".
> KIP-4 does not change the Authorizer interface at all, but does provide
> java objects in "org.apache.kafka.common.security.auth" to be used in the
> protocol request/response classes. It also provides translations between
> the Java and Scala versions for server side compatibility with
> the Authorizer interface.
>
> List ACLs Request
>
>
>
> ListAcls Request (Version: 0) => principal resource
>   principal => NULLABLE_STRING
>   resource => resource_type resource_name
>     resource_type => INT8
>     resource_name => STRING
>
> Request semantics:
>
>    1. Can be sent to any broker
>    2. If a non-null principal is provided the returned ACLs will be
>    filtered by that principle, otherwise ACLs for all principals will be
>    listed.
>    3. If a resource with a resource_type != -1 is provided ACLs will be
>    filtered by that resource, otherwise ACLs for all resources will be listed.
>    4. Any principle can list their own ACLs where the permission type is
>    "Allow", Otherwise the principle must be authorized to the "All" Operation
>    on the "Cluster" resource to list ACLs.
>    - Unauthorized requests will receive a ClusterAuthorizationException
>       - This avoids adding a new operation that an existing authorizer
>       implementation may not be aware of.
>       - This can be reviewed and further refined/restricted as a follow
>       up ACLs review after this KIP. See Follow Up Changes
>       <https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-follow-up-changes>
>       .
>    5. Requesting a resource or principle that does not have any ACLs will
>    not result in an error, instead empty response list is returned
>
> List ACLs Response
>
>
>
> ListAcls Response (Version: 0) => [responses] error_code
>   responses => resource [acls]
>     resource => resource_type resource_name
>       resource_type => INT8
>       resource_name => STRING
>     acls => acl_principle acl_permission_type acl_host acl_operation
>       acl_principle => STRING
>       acl_permission_type => INT8
>       acl_host => STRING
>       acl_operation => INT8
>   error_code => INT16
>
> Alter ACLs Request
>
>
>
> AlterAcls Request (Version: 0) => [requests]
>   requests => resource [actions]
>     resource => resource_type resource_name
>       resource_type => INT8
>       resource_name => STRING
>     actions => action acl
>       action => INT8
>       acl => acl_principle acl_permission_type acl_host acl_operation
>         acl_principle => STRING
>         acl_permission_type => INT8
>         acl_host => STRING
>         acl_operation => INT8
>
> Request semantics:
>
>    1. Must be sent to the controller broker
>    2. If there are multiple instructions for the same resource in one
>    request an InvalidRequestException will be logged on the broker and a
>    single error code for that resource will be returned to the client
>       - This is because the list of requests is modeled server side as a
>       map with resource as the key
>    3. ACLs with a delete action will be processed first and the add
>    action second.
>    1. This is to prevent confusion about sort order and final state when
>       a batch message is sent.
>       2. If an add request was processed first, it could be deleted right
>       after.
>       3. Grouping ACLs by their action allows batching requests to the
>       authorizer via the Authorizer.addAcls and Authorizer.removeAcls calls.
>    4. The request is not transactional. One failure wont stop others from
>    running.
>       1. If an error occurs on one action, the others could still be run.
>       2. Errors are reported independently.
>       5. The principle must be authorized to the "All" Operation on the
>    "Cluster" resource to alter ACLs.
>       - Unauthorized requests will receive a ClusterAuthorizationException
>       - This avoids adding a new operation that an existing authorizer
>       implementation may not be aware of.
>       - This can be reviewed and further refined/restricted as a follow
>       up ACLs review after this KIP. See Follow Up Changes
>       <https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-follow-up-changes>
>       .
>
> QA:
>
>    - Why doesn't this request have a timeout and implement any blocking
>    like the CreateTopicsRequest?
>       - The Authorizer implementation is synchronous and exposes no
>       details about propagating the ACLs to other nodes.
>       - The best we can do in the existing implementation is
>       call Authorizer.addAcls and Authorizer.removeAcls and hope the underlying
>       implementation handles the rest.
>    - What happens if there is an error in the Authorizer?
>       - Currently the best we can do is log the error broker side and
>       return a generic exception because there are no "standard" exceptions
>       defined in the Authorizer interface to provide a more clear code
>       - KIP-50
>       <https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Move+Authorizer+to+o.a.k.common+package#KIP-50-MoveAuthorizertoo.a.k.commonpackage-AddexceptionsrelatedtoAuthorizer.>
is
>       tracking adding the standard exceptions
>       - The Authorizer interface also provides no feedback about
>       individual ACLs when added or deleted in a group
>       - Authorizer.addAcls is a void function, the best we can do is
>          return an error for all ACLs and let the user check the current state by
>          listing the ACLs
>          - Autohrizer.removeAcls is a boolean function,  the best we can
>          do is return an error for all ACLs and let the user check the current state
>          by listing the ACLs
>          - Behavior here could vary drastically between implementations
>          - I suggest this be addressed in KIP-50 as well, though it has
>          some compatibility concerns.
>       - Why require the request to go to the controller?
>       - The controller is responsible for the cluster metadata and its
>       propagation
>       - This ensures one instance of the Authorizer sees all the changes
>       and reduces concurrency issues, especially because the Authorizer interface
>       exposes no details about propagating the ACLs to other nodes.
>       - See Request Forwarding
>       <https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-request>
>        below
>
> Alter ACLs Response
>
>
>
> AlterAcls Response (Version: 0) => [responses]
>   responses => resource [results]
>     resource => resource_type resource_name
>       resource_type => INT8
>       resource_name => STRING
>     results => action acl error_code
>       action => INT8
>       acl => acl_principle acl_permission_type acl_host acl_operation
>         acl_principle => STRING
>         acl_permission_type => INT8
>         acl_host => STRING
>         acl_operation => INT8
>       error_code => INT16
>
>
>

Thank you,
Grant
-- 
Grant Henke
Software Engineer | Cloudera
grant@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message