skip to content

What does connector.client.config.override.policy do, and why is it set to None by default?

level: middleimportance: must knowfreq 60%

answer

  1. worker config controlling per-connector overrides
  2. None / Principal / All
  3. producer.override. / consumer.override. / admin.override.
  4. Principal = per-connector credentials only
  5. fail-safe default = None

basics

~10 s

It's a worker-level setting that controls whether individual connectors can override the worker's Kafka client configs using producer.override./consumer.override./admin.override. prefixes. Defaults to None (no overrides allowed); common values are All or Principal.

solid answer

~40 s

By default a connector inherits the worker's producer/consumer/admin client configs and cannot change them. `connector.client.config.override.policy` is a worker config naming a `ConnectorClientConfigOverridePolicy` implementation that decides which overrides a connector may set via the `producer.override.`, `consumer.override.`, and `admin.override.` prefixes in its connector config. Built-in policies: `None` (default — no overrides), `All` (any client config), and `Principal` (only security-principal-related configs like sasl.jaas.config, so each connector can authenticate as its own identity while not changing other behavior). It defaults to None because a connector config is often submitted by less-trusted users via the REST API; allowing arbitrary client overrides could let a connector point at a different cluster, weaken TLS, or impersonate. Principal is the typical production choice for multi-tenant workers needing per-connector credentials.

go deeper

for a junior

Know the setting exists and defaults to None, blocking per-connector client overrides.

for a middle

Explain None/Principal/All and the .override. prefixes a connector uses.

for a senior

Justify Principal for multi-tenancy and pair it with per-principal broker ACLs.

for a principal

Design a custom override policy / tenancy model and reason about the threat model of arbitrary overrides.

**The problem it solves:** A Connect worker runs many connectors, but all of them, by default, share the worker's single producer/consumer/admin configuration — including one identity to the broker. In multi-tenant setups you often want connector A to authenticate as principal A and connector B as principal B (for per-tenant ACLs and quotas), or to tune client settings per connector. But connector configs are submitted at runtime over the REST API, possibly by users you trust less than the operator who launched the worker. Letting them set arbitrary client configs is dangerous. **The mechanism:** The worker config `connector.client.config.override.policy` names a class implementing `org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy`. When a connector config contains keys prefixed with `producer.override.`, `consumer.override.`, or `admin.override.`, the worker asks the policy whether each override is permitted. If the policy rejects it, the connector fails validation. **Built-in policies:** - `None` (default): no overrides allowed at all. Any `*.override.*` key is rejected. - `All`: every client config may be overridden — maximum flexibility, least safe. - `Principal`: only configs relevant to the security principal may be overridden — specifically `security.protocol`, `sasl.*`, and `ssl.*` keys grouped as principal/security configs. This lets each connector present its own credentials without being able to redirect to another cluster's data plane behaviour broadly. **How a connector uses it:** Once the policy allows overrides, the connector config sets e.g. `producer.override.sasl.jaas.config=...` to give a source connector its own broker identity, or `consumer.override.max.poll.records=...` to tune a sink. Note the **double** marker: `producer.override.` at the connector level, which the worker strips to `producer.` for that connector's client. (Contrast: at the *worker* level you'd write `producer.sasl.jaas.config` directly.) **Why None by default — security rationale:** With `All`, a malicious or careless connector config could set `producer.override.bootstrap.servers` to exfiltrate to another cluster, disable TLS with `producer.override.security.protocol=PLAINTEXT`, or `producer.override.ssl.endpoint.identification.algorithm=` (empty) to skip hostname verification. Defaulting to None is fail-safe. **Edge case:** even with `Principal`, you should still scope broker ACLs per principal so a stolen credential is limited; the override policy controls *what configs* can change, not *what a principal can do* on the broker. **Custom policies:** You can implement your own `ConnectorClientConfigOverridePolicy` (it's a pluggable interface) to, say, allow only a specific allowlist of keys, and register it by class name in the worker config.

  • Why is Principal often preferred over All in production?
    Principal lets each connector authenticate as its own identity (for per-tenant ACLs/quotas) while preventing connectors from changing non-security configs like bootstrap.servers or disabling TLS hostname verification — least privilege.
  • At the connector level, what prefix gives a source connector its own producer credentials?
    producer.override. — e.g. producer.override.sasl.jaas.config. The worker strips the .override. and applies it to that connector's producer.
  • Does the override policy restrict what the connector's principal can do on the broker?
    No. It only controls which client configs the connector config may override. Authorization on the broker is still governed by ACLs for that principal.

saying these in an interview costs you the question

  • Saying overrides are allowed by default (default is None)
  • Confusing worker-level producer. with connector-level producer.override.
  • Claiming the override policy enforces broker ACLs (it doesn't — broker ACLs are separate)
  • Thinking Principal allows overriding bootstrap.servers (it's limited to security/principal configs)

context

resolving links…