...

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.

This KIP proposes adding a getSupportedPrincipalTypes method to authorizer and use that for acls verification during acls CRUD.

Public Interfaces

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

/**
* gets setdescription of principal types supported by configured authorizerauthorizer implementation.
* @return setdescription containingof only "User" as principal type if Authorizer implementation does not provide this information,
* else set of principal types supported by the configured authorizerauthorizer implementation.
*/
def getSupportedPrincipalTypesgetDescription(): Set[String]

Proposed Changes

The KIP proposes to add getSupportedPrincipalTypes 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. AclCommand can use that info to perform ACLs validation. By default, getSupportedPrincipalTypes will return Set(KafkaPrincipal.USER_TYPE)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.Once this method is added we expect the Client of the authorizer to do the validation on principal types and the authorizer will still not do any validation by it self. 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?
  • There is no behavior change. KIP proposal is to make sure users don't make unintended mistakes.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.