...

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. It should be noted that we have not found a specific vulnerability in relation to KafkaConnect, but are attempting to reduce the ability for a theoretical attacker (or audit team) to fuzz APIs and produce more information that is acceptable in highly secure environments.

Public Interfaces

No new public interfaces are proposed.

...

We are proposing addition of a new ExceptionMapper called HardenedConnectExceptionMapper, which has an alternative behavior of printing a static SUPRESSED_EXCEPTION_MESSAGE (Suggested: "Detailed exception information has been suppressed. Please see logs." in this PR) 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.called rest.response.messagestack.detail.enabled traces which would default to true. Disabling message detail would enable the “hardened security mode.”

This KIP is for handling all exceptions handled by the ExceptionMapper, including ConnectRestExceptions. An example of this is here, in this PR on GitHub.

There is an outstanding question on the message board related to other Exceptions here. The KIP originator is working with his customer sponsor and determining their needs and intentions.

Compatibility, Deprecation, and Migration Plan

...

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

Proposed by the community was a Connect REST extension as an alternative to an Nginx proxy. We had not considered using one. It was suggested that a REST extension shouldn't be necessary in order to lock down the REST API in the way proposed by the KIP. It was deemed an acceptable workaround in cases where users are stuck on a given version of Connect and can't upgrade to the upstream version of Kafka that this KIP is merged into.

Tuning ssl.* parameters to provide guarantee of privacy (encryption) and authenticity (PKI) does not provide us with authentication, which would provide a "gate" around the ability to fuzz, and an audit trail on "who is fuzzing," except by IP, which could then be combined with Fail2Ban or similar log analysis mitigations. Since authorization seems like a more major change, we're suggesting that we just remove the data we've considered "harmful."