The connector.client.config.override.policy setting decides which Kafka client properties a connector may override in its own config. Per the Apache Kafka docs the default is All, which lets connector configs override everything. None blocks all overrides, and Principal allows overriding only client principals.
What the setting controls
Connect workers create Kafka clients for connectors: producers, consumers and admin clients. Worker level properties set the defaults, and individual connector configs can carry override entries with a prefix such as producer.override or consumer.override. The override policy is the rule that says which of those entries the worker honours.
The Kafka worker configuration reference states it plainly: the property gives the class name or alias of a ConnectorClientConfigOverridePolicy implementation, defines what client configurations a connector can override, defaults to All, with None and Principal among the framework's other policies.
Why the default deserves a look
If anyone who can create or edit a connector can override any client property, they can change more than tuning knobs. Security related client settings, such as which principal the client authenticates as, are among the properties that can be overridden under All. In a shared Connect cluster, that is a way for one team's connector config to act with a different identity than the platform team intended.
Whether that matters depends on who can create connectors. If only a deployment pipeline does, the risk is small. If many teams can, tighten it.
| Policy | What connectors may override | Fits |
|---|---|---|
| All (default) | Any client property | Single team clusters with controlled access |
| Principal | Client principals only | Clusters where each connector needs its own identity |
| None | Nothing | Shared clusters where the platform team owns client settings |
A practical decision
- Decide who may create connectors and how those requests are reviewed.
- If each connector must use its own service identity with narrow ACLs, choose Principal, so connectors can set their identity but nothing else.
- If client settings should be fully centralised, choose None.
- Keep All only where you can show that connector configs are reviewed.
The Kafka docs also mention a legitimate use of overrides: a sink connector's consumer can set its isolation level through an override when the policy allows it, as part of exactly once support. If you move to None, test any connectors that rely on overrides like that before rollout.
Pair it with ACLs
An override policy is one layer. The Kafka side still needs ACLs that match each connector identity, so that a connector can read or write only the topics it needs. See Kafka ACLs: least privilege producer and consumer setup and who can reach the Kafka Connect REST API on port 8083.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a change is blocked until a rule passes. Connector configs kept in Git can go through the same kind of review.
Safeguard's policies and gates can check changes in a repository before merge. A free scan is at gold.safeguard.sh/scan.
Quick check
What does the default policy allow?
All, meaning a connector configuration can override all client properties, per the Apache Kafka worker config reference.
Which policy keeps connectors to their own identity only?
Principal, which allows connectors to override only client principals.
Sources
- Kafka Connect configs, Apache Kafka documentation, fetched 19 October 2026.
- Kafka Connect user guide, Apache Kafka documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
