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

Compare with Current View Page History

Version 1 Next »

This KIP is aimed at providing a more secure alternative error body in the message passed by the REST exception mapper in Kafka Connect. When Kafka Connect handles a catch-all exception, it prints the message of that exception, which could lead to future security issues and disclosures of information not desired in sensitive environments. In environments that require high levels of security, security teams have requested Kafka Connect intentionally obfuscate these messages. This KIP would allow these environments to anticipate this intentionally obfuscated error response in exchange for higher security.

Status

Current state: Under Discussion

Discussion thread: here

JIRA: KAFKA-9766

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

Motivation

It is expected that all unhandled exceptions be caught by a catch-all exception mapper. However, in some sensitive environments, it is more harmful than helpful to disclose what the nature of that unhandled exception is. In most environments, it is useful to know the nature of all exceptions, so that errors can be caught by monitoring systems. In this case, we are aware of customers who have had to scrutinize their use of Kafka Connect in these secure environments because of their inability to tune this response.

Public Interfaces

No new public interfaces are proposed.

Proposed Changes

We are proposing addition of a new ExceptionMapper called HardenedConnectExceptionMapper, which has an alternative behavior of printing a static SUPRESSED_EXCEPTION_MESSAGE instead of reading the exception.getMessage(). Because other contributors might have additional requirements around this KIP in the future, the original contributor of this KIP thought it best to create a separate class that might have a different implementation instead of modifying ConnectExceptionMapper.

This ExceptionMapper should be configured to be loaded based on the worker config. Proposed is a new configuration called error.rest.response.message.detail.enabled which would default to true. Disabling message detail would enable the “hardened security mode.”

Compatibility, Deprecation, and Migration Plan

  • If enabled, the output of the API on an error response will change. The schema of the REST response should be the same.

  • The old behavior will remain the default, this KIP asks the community to support an additional way of reporting errors into the future
  • No tools are needed for migration
  • The existing behavior will not be deprecated

Rejected Alternatives

We have considered putting an NGINX reverse proxy in front of Kafka Connect in these environments, but we rejected this alternative because this kind of web application firewall becomes heavy for something as lightweight as Kafka Connect

  • No labels