...

Current state: ["DISCUSSION"]. 

Discussion thread: here

JIRA: KAFKA-1696 

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

...

1.  Support for master key rotation. Some of the available alternatives are given in below section.
    Support impersonation use cases: Allow users to acquire
   • delegation
   tokens on behalf of other users

Alternatives

Originally we considered to not have any shared Secret at config level. This required us to chose one of the options below:

...

1. • .token.master.key could be a list, which would allow users to support both a new and old key at the same time while clients are upgrading tokens.
   • Use the controller to generate and rotate secret and distribute it to all brokers. Brokers will generate hmac based on *current* secret. The advantage is secret rotation can be more frequent and automated. The disadvantage is added complexity to push/pull tokens from the controller to brokers and brokers needs to keep a list of valid secrets till max( max life time of all tokens).

...

delegation.token.master.key could be a list, which would allow users to support both a new and old key at the same time while clients are upgrading tokens.

1. • Let each broker generate a Random secret on each acquisition request and use this secret to generate the hmac. Broker will store the hmac and secret in zookeeper. However as zkClient does not support SSL the hmac will be on wire unencrypted which is not safe.

2.  Support impersonation use cases: Allow users to acquire delegation tokens on behalf of other users

...