Status

Current state: Accepted

Discussion thread: thread

Vote thread: thread

JIRA: KAFKA-19824 - Getting issue details... STATUS

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

Motivation

Kafka Connect allows connectors to override client configurations. While this is powerful and in many cases critical to successfully run a Connect pipeline, this has proved an issue from a security point of view. Since 2023, we've had the following CVEs against Connect all relying on client overrides:

  • CVE-2023-25194: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration using Apache Kafka Connect API

  • CVE-2024-31141: Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients

  • CVE-2025-27818: Apache Kafka: Possible RCE attack via SASL JAAS LdapLoginModule configuration

  • CVE-2025-27819: Apache Kafka: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration

Kafka Connect has ConnectorClientConfigOverridePolicy plugins that allow administrators to police what client configurations can be overridden by connectors. This however defaults to "All" which allows overriding all configurations. Kafka provides 2 other built-in policies, "None" which prevents all overrides and "Principal" which only allows overriding sasl.jaas.config, sasl.mechanism and security.protocol. Before Kafka 3.0.0, the default policy was "None", it was changed to "All" via KIP-722.

The "None" policy is very restrictive but the other 2 alternatives have proved unsafe. Kafka should provide a safe and flexible policy so administrators can control exactly the list of configurations they want to allow without having to write a custom policy.

Public Interfaces

A new built-in ConnectorClientConfigOverridePolicy implementation will be created, AllowlistConnectorClientConfigOverridePolicy. This policy will have one configuration:

Name: connector.client.config.override.allowlist
Type: List
Default: Empty
Documentation: List of client configurations that can be overridden by connectors. If empty, connectors can't override any client configurations.

Proposed Changes

When a users sets connector.client.config.override.policy to "Allowlist", they can set connector.client.config.override.allowlist configuration to the list of producer, consumer and admin configurations they allow connectors to override.

For example, the following configuration only allows connectors to override the linger.ms and client.id configurations.

connector.client.config.override.policy=Allowlist
connector.client.config.override.allowlist=linger.ms,client.id

I also propose making this implementation the default from the next major Kafka release and update the connector.client.config.override.policy documentation appropriately.

We will also deprecate PrincipalConnectorClientConfigOverridePolicy. The reason is that it's proven a security pain point and we've not updated it to support all the new sasl configurations added other the years. 

Compatibility, Deprecation, and Migration Plan

This is a new policy, so only users configuring their Connect runtime to use it will see a change of behavior. 

In the next major release, Kafka 5.0, users relying on client configuration overrides will need to set connector.client.config.override.allowlist appropriately. They can use the Connect REST API to identify all the client configurations override used by the defined connectors.

PrincipalConnectorClientConfigOverridePolicy will be deprecated and marked for deletion in Kafka 5.0. Users will be able to reproduce its exact behavior by using the new Allowlist policy with connector.client.config.override.allowlist set to "sasl.jaas.config,sasl.mechanism,security.protocol".

Test Plan

We will test this new policy with unit tests like we currently do for the existing ConnectorClientConfigOverridePolicy implementations.

Rejected Alternatives

  • Switch back the default value of connector.client.config.override.policy to None. This would break existing environments that depend on client configuration overrides.
  • Do nothing and ask Connect cluster administrators to implement their own ConnectorClientConfigOverridePolicy if they want granular control over the client configuration overrides.
  • No labels