...

This KIP is aimed at providing a more secure an alternative error body that never includes a stack trace in the message passed by the REST exception mapper in in REST responses by Kafka Connect. When For example, 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.

...

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. Additionally, this KIP asks that we examine the code base for additional instances of stack traces in handled/OK/200 responses to provide an alternative body for the stack trace.

Public Interfaces

No new public interfaces are proposedWe are proposing an alternative expected value to a variety of REST responses. This means that the JSON schema for affected responses should not change, but the values in that schema, for example, a stack trace, would be replaced by a static string.

Proposed Changes

We are proposing addition of a new ExceptionMapper called HardenedConnectExceptionMapper, which has a config-based behavior branch in the ExceptionMapper, which would have 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.Additionally, we would identify classes that print stack traces in their REST responses, such as /connectors/{name}/status, which prints the "trace" field, and implement an alternative behavior as in the ExceptionMapper.

This ExceptionMapper behavior change and other affected classes This ExceptionMapper should be configured to be loaded changed based on the worker config. Proposed is a new configuration called enable.rest.response.stack.traces which would default to true. Disabling message detail would enable the “hardened security mode.”

This KIP is for includes 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

...