Page History

...

• internal.request.key.generation.algorithm
  • Purpose: the algorithm used to generate session keys
  • Type: string
  • Default: "HmacSHA256"
  • Importance: low
• internal.request.key.size
  • Purpose: the size of generated session keys, in bits; if null, the default key size for the generation algorithm will be used (see the KeyGenerator Javadocs; specifically: "In case the client does not explicitly initialize the KeyGenerator (via a call to an init method), each provider must supply (and document) a default initialization.")
  • Type: int
  • Default: null
  • Importance: low
• internal.request.key.rotation.interval.ms
  • Purpose: how often to force a rotation of the internal key used for request validation, or 0 if forced rotation should never occur
  • Type: long
  • Default: 3600000 (one hour)
  • Importance: low
• internal.request.signature.algorithm
  • Purpose: the algorithm to use to sign internal requests when sent from a follower worker to the leader
  • Type: string
  • Default: "HmacSHA256"
  • Importance: low
• internal.request.verification.algorithms
  • Purpose: a list of supported algorithms for verifying internal requests that are received by the leader from a follower. This list must include the value provided for the internal.request.signature.algorithm property
  • Type: list
  • Default: "HmacSHA256"
  • Importance: low

...

Possible failure scenarios

Failure to relay task configurations to leader due to incorrect configuration

The only seriously bad scenario is if a follower worker is configured to use a request signing algorithm that isn't allowed by the leader. In this case, any failure will only occur if/when that follower starts up a connector and then has to forward tasks for that connector to the leader, which may not happen immediately. Once that failure occurs, an endless failure loop will occur wherein the follower endlessly retries to send those task configurations to the leader and pauses by the backoff interval in between each failed request.

There are two ways to rectify this situation; either shut down the follower and restart it after editing its configuration to use a request signing algorithm permitted by the leader, or shut down all other workers in the cluster that do not permit the request signing algorithm used by the follower, reconfigure them to permit it, and then restart them.

This scenario is unlikely to occur with any normal usage of Connect, but the circumstances leading to it will need to be called out very carefully (in the upgrade notes for any release that begins to support this new behavior) in order to avoid putting the cluster into a bad state and flooding logs with scary-looking error messages. Additionally, it will be vital to design appropriate error messages for this scenario so that users can (hopefully) dig themselves out of that hole on their own.

Differing values for any of the other configurations in this KIP shouldn't actually be too problematic, given that the remaining ones all deal with key generation/rotation, which is only handled by one worker at a time (the leader).

Accidental disabling of internal request verification

There are two scenarios that may indicate that the user has accidentally disabled internal request verification; these should result in warn-level log messages that carefully explain that request verification is disabled, what has caused request verification to become disabled, and how the user can fix this if desired.

...