You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Status

Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: KAFKA-3186

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

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

Public Interfaces

Add following public methods to kafka.security.auth.Authorizer interface.

/**
* gets description of authorizer implementation.
* @return description of authorizer implementation.
*/
def getDescription(): String

Proposed Changes

The KIP proposes to add getDescription() to Authorizer interface. Each authorizer implementation can override this method to provide info on implementation specific aspects of authorizer, for instance, Principal Types it supports. The description will be provided by {{kafka-acls.sh}} CLI when --help is specified. The KIP suggests that acls should be validated in authorizer implementations.

By default, getDescription will return empty String. This will ensure that authorizers won't have to make changes to continue working, unless they want to utilize this information. The changes will be source compatible, but binary incompatible. For using CLI and/or AdminCommand from >= 0.10, authorizer implementations will have to be recompiled against 0.10 dependency.

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
    • Users will get error when trying to add Principal types that authorizer does not support. So, less silent errors. Users can use CLI's help to find supported principal types.
  • If we are changing behavior how will we phase out the older behavior?
    • NA
  • If we need special migration tools, describe them here.
    • None.
  • When will we remove the existing behavior?
    • NA.

Rejected Alternatives

  • Add getSupportedPrincipalTypes in authorizer interface.
  • Add validation at Authorizer level.
  • An alternative of providing supported Principal types via interface is via a config option.
  • No labels