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

Compare with Current View Page History

« Previous Version 8 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.

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 set of principal types supported by configured authorizer.
* @return set containing only "User" as principal type if Authorizer implementation does not provide this information,
* else set of principal types supported by the configured authorizer.
*/
def getSupportedPrincipalTypes(): Set[String]

Proposed Changes

The KIP proposes to add getSupportedPrincipalTypes to Authorizer interface. Each authorizer implementation can override this method to provide info on Principal Types it supports. AclCommand can use that info to perform ACLs validation. By default, getSupportedPrincipalTypes will return Set(KafkaPrincipal.USER_TYPE). 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.

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.
  • 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.
  • If we need special migration tools, describe them here.
    • None.
  • When will we remove the existing behavior?
    • NA.

Rejected Alternatives

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