<a id="connect-allconfigs"></a>

# Kafka Connect Worker Configuration Properties for Confluent Platform

Kafka Connect worker configuration properties define how Connect instances operate
and interact with the Apache Kafka® cluster. You can configure common properties for both standalone
and distributed modes to manage core settings, such as cluster connection details and data
formats. You can also use mode-specific properties to tune the standalone or distributed worker configurations.

For additional configuration properties see the following sections:

* Connect and Schema Registry: See [Integrate Schemas from Kafka Connect in Confluent Platform](../../schema-registry/connect.md#schemaregistry-kafka-connect).
* Producer configuration properties: See [Kafka Producer for Confluent Platform](../../clients/producer.md#kafka-producer).
* Consumer configuration properties: See [Kafka Consumer for Confluent Platform](../../clients/consumer.md#kafka-consumer).
* TLS/SSL encryption properties: See [Protect Data in Motion with TLS Encryption in Confluent Platform](../../security/protect-data/encrypt-tls.md#kafka-ssl-encryption).
* All Kafka configuration properties: See [Kafka Configuration Reference for Confluent Platform](../../installation/configuration/index.md#cp-config-reference).

For information about how the Connect worker functions, see [Configuring and Running Workers](/kafka-connectors/self-managed/userguide.html#configuring-and-running-workers).

<a id="connect-common-work-config"></a>

## Common Worker Configuration

`bootstrap.servers`
: A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping - this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form `host1:port1,host2:port2,...`. Since these servers are just used for the initial connection to discover the full cluster membership (which may change dynamically), this list need not contain the full set of servers (you may want more than one, though, in case a server is down).
  <br/>
  * Type: list
  * Default: [localhost:9092]
  * Importance: high

`key.converter`
: Converter class for key Connect data. This controls the format of the data that will be written to Kafka for source connectors or read from Kafka for sink connectors. Popular formats include Avro and JSON.
  <br/>
  * Type: class
  * Default:
  * Importance: high

`value.converter`
: Converter class for value Connect data. This controls the format of the data that will be written to Kafka for source connectors or read from Kafka for sink connectors. Popular formats include Avro and JSON.
  <br/>
  * Type: class
  * Default:
  * Importance: high

`internal.key.converter`
: Converter class for internal key Connect data that implements the `Converter` interface. Used for converting data like offsets and configs.
  <br/>
  * Type: class
  * Default:
  * Importance: low

`internal.value.converter`
: Converter class for offset value Connect data that implements the `Converter` interface. Used for converting data like offsets and configs.
  <br/>
  * Type: class
  * Default:
  * Importance: low

`offset.flush.interval.ms`
: Interval at which to try committing offsets for tasks.
  <br/>
  * Type: long
  * Default: 60000
  * Importance: low

`offset.flush.timeout.ms`
: Maximum number of milliseconds to wait for records to flush and partition offset data to be committed to offset storage before cancelling the process and restoring the offset data to be committed in a future attempt.
  <br/>
  * Type: long
  * Default: 5000
  * Importance: low

`plugin.path`
: The comma-separated list of paths to directories that contain [Kafka Connect plugins](/kafka-connectors/self-managed/userguide.html#installing-kconnect-plugins).
  <br/>
  * Type: string
  * Default:
  * Importance: low

`rest.advertised.host.name`
: If this is set, this is the hostname that will be given out to other Workers to connect to.
  <br/>
  * Type: string
  * Importance: low

`rest.advertised.listener`
: Configures the listener used for communication between Workers. Valid values are either `http` or `https`.  If the
  listeners property is not defined or if it contains an HTTP listener, the default value for this field is `http`.
  When the listeners property is defined and contains only HTTPS listeners, the default value is `https`.
  <br/>
  * Type:  string
  * Importance: low

`rest.advertised.port`
: If this is set, this is the port that will be given out to other Workers to connect to.
  <br/>
  * Type: int
  * Importance: low

`listeners`
: A list of REST listeners in the format
  `protocol://host:port,protocol2://host2:port2` that determines the
  protocol used by Kafka Connect, where the protocol is either
  HTTP or HTTPS. For example:
  <br/>
  ```bash
  listeners=http://localhost:8080,https://localhost:8443
  ```
  <br/>
  By default, if no listeners are specified, the REST server runs on port 8083
  using the HTTP protocol. When using HTTPS, the configuration must include the
  TLS/SSL configuration. For more details, see [Configuring the Connect REST API for HTTP or HTTPS](../security.md#connect-rest-api-http).
  <br/>
  * Type: list
  * Importance: low

`response.http.headers.config`
: Used to select which HTTP headers are returned in the HTTP response for Confluent Platform
  components. Specify multiple values in a comma-separated string using the
  format `[action][header name]:[header value]` where `[action]` is one of
  the following: `set`, `add`, `setDate`, or `addDate`. You must use
  quotation marks around the header value when the header value contains commas. For example:
  <br/>
  ```none
  response.http.headers.config="add Cache-Control: no-cache, no-store, must-revalidate", add X-XSS-Protection: 1; mode=block, add Strict-Transport-Security: max-age=31536000; includeSubDomains, add X-Content-Type-Options: nosniff
  ```
  <br/>
  * Type: string
  * Default: “”
  * Importance: low

`task.shutdown.graceful.timeout.ms`
: Amount of time to wait for tasks to shutdown gracefully. This is the total amount of time, not per task. All task have shutdown triggered, then they are waited on sequentially.
  <br/>
  * Type: long
  * Default: 5000
  * Importance: low

<a id="connect-standalone-work-config"></a>

## Standalone Worker Configuration

In addition to the common Worker configuration options, the following is available in standalone mode.

`offset.storage.file.filename`
: The file to store connector offsets in. By storing offsets on disk, a standalone process can be stopped and started on a single node and resume where it previously left off.
  <br/>
  * Type: string
  * Default: “”
  * Importance: high

<a id="connect-dist-work-config"></a>

## Distributed Worker Configuration

In addition to the common worker configuration options, the following are
available in distributed mode. For information about how the Connect worker
functions, see [Configuring and Running
Workers](/kafka-connectors/self-managed/userguide.html#configuring-and-running-workers).

`group.id`
: A unique string that identifies the Connect cluster group this Worker belongs to.
  <br/>
  Note the following:
  <br/>
  - For production environments, you must explicitly set this configuration.
    When using the [Confluent CLI](https://docs.confluent.io/confluent-cli/current/index.html), this
    configuration property is set to `connect-cluster` by default. All
    workers with the same `group.id` will be in the same Connect cluster.
    For example, if worker A has `group.id=connect-cluster-a` and worker B
    has the same `group.id`, worker A and worker B form a cluster called
    `connect-cluster-a`.
  - A sink connector’s consumer uses a separate `group.id` for tracking
    offsets, distinct from the Connect cluster `group.id` described
    above. Connect determines this `group.id` using the following
    precedence:
    1. By default, Connect uses `connect-` followed by the
       connector name.
    2. If you set `consumer.group.id` in the worker properties file,
       it overrides the default for **all** sink connectors on that
       worker.
    3. If you set `consumer.override.group.id` in an individual
       connector’s configuration, it overrides the `group.id` for
       **that connector only**.
  <br/>
    To set `consumer.override.group.id` on a connector, you must
    first configure the worker to permit per-connector client
    overrides:
    ```bash
    connector.client.config.override.policy=All
    ```
  <br/>
  * Type: string
  * Default: “”
  * Importance: high

`config.storage.topic`
: The name of the topic where connector and task configuration data are stored. This *must* be the same for all Workers with the same `group.id`.
  Kafka Connect will upon startup attempt to automatically create this topic with a single-partition and compacted cleanup policy to avoid losing data,
  but it will simply use the topic if it already exists. If you choose to create this topic manually, **always** create it as a compacted topic
  with a single partition and a high replication factor (3x or more).
  <br/>
  * Type: string
  * Default: “”
  * Importance: high

`config.storage.replication.factor`
: The replication factor used when Kafka Connects creates the topic used to store connector and task configuration data. This should **always**
  be at least `3` for a production system, but cannot be larger than the number of Kafka brokers in the cluster. Enter `-1` to use the Kafka broker default replication factor.
  <br/>
  * Type: short
  * Default: 3
  * Importance: low

`offset.storage.topic`
: The name of the topic where connector and task configuration offsets are stored. This *must* be the same for all Workers with the same `group.id`.
  Kafka Connect will upon startup attempt to automatically create this topic with multiple partitions and a compacted cleanup policy to avoid losing
  data, but it will simply use the topic if it already exists. If you choose to create this topic manually, **always** create it as a compacted,
  highly replicated (3x or more) topic with a large number of partitions (e.g., 25 or 50, just like Kafka’s built-in `__consumer_offsets` topic) to
  support large Kafka Connect clusters.
  <br/>
  * Type: string
  * Default: “”
  * Importance: high

`offset.storage.replication.factor`
: The replication factor used when Connect creates the topic used to store connector offsets. This should **always**
  be at least `3` for a production system, but cannot be larger than the number of Kafka brokers in the cluster. Enter `-1` to use the Kafka broker default replication factor.
  <br/>
  * Type: short
  * Default: 3
  * Importance: low

`offset.storage.partitions`
: The number of partitions used when Connect creates the topic used to store connector offsets. A large value
  (e.g., `25` or `50`, just like Kafka’s built-in `__consumer_offsets` topic) is necessary to support large Kafka Connect clusters. Enter `-1` to use the default number of partitions configured in the Kafka broker.
  <br/>
  * Type: int
  * Default: 25
  * Importance: low

`status.storage.topic`
: The name of the topic where connector and task configuration status updates are stored. This *must* be the same for all Workers
  with the same `group.id`. Kafka Connect will upon startup attempt to automatically create this topic with multiple partitions and a compacted cleanup policy to avoid losing data, but it will simply use the topic if it already exists. If you choose to create this topic manually, **always** create it as a compacted, highly replicated (3x or more) topic with multiple partitions.
  <br/>
  * Type: string
  * Default: “”
  * Importance: high

`status.storage.replication.factor`
: The replication factor used when Connect creates the topic used to store connector and task status updates.
  This should **always** be at least `3` for a production system, but cannot be larger than the number of Kafka brokers in the cluster. Enter `-1` to use the Kafka broker default replication factor.
  <br/>
  * Type: short
  * Default: 3
  * Importance: low

`status.storage.partitions`
: The number of partitions used when Connect creates the topic used to store connector and task status updates. Enter `-1` to use the default number of partitions configured in the Kafka broker.
  <br/>
  * Type: int
  * Default: 5
  * Importance: low

`heartbeat.interval.ms`
: The expected time between heartbeats to the group coordinator when using
  Kafka’s group management facilities. Heartbeats are used to ensure that the
  Worker’s session stays active and to facilitate rebalancing when new members
  join or leave the group. The value must be set lower than
  `session.timeout.ms`, but typically should be set no higher than 1/3 of that
  value. It can be adjusted even lower to control the expected time for normal
  rebalances.
  <br/>
  * Type: int
  * Default: 3000
  * Importance: high
  <br/>
  The `heartbeat.interval.ms` setting is ignored when `group.protocol =
  consumer`, instead use the broker configuration `group.consumer.heartbeat.interval.ms` to
  control the heartbeat.

`session.timeout.ms`
: The timeout used to detect failures when using Kafka’s group management
  facilities.
  <br/>
  * Type: int
  * Default: 30000
  * Importance: high
  <br/>
  The `session.timeout.ms` setting is ignored when `group.protocol =
  consumer`, instead use the broker configuration `group.consumer.session.timeout.ms` to
  control the timeout.

`ssl.key.password`
: The password of the private key in the key store file. This is optional for client.
  <br/>
  * Type: password
  * Importance: high

`ssl.keystore.location`
: The location of the key store file. This is optional for client and can be used for two-way client authentication.
  <br/>
  * Type: string
  * Importance: high

`ssl.keystore.password`
: The store password for the key store file.This is optional for client and only needed if ssl.keystore.location is configured.
  <br/>
  * Type: password
  * Importance: high

`ssl.truststore.location`
: The location of the trust store file.
  <br/>
  * Type: string
  * Importance: high

`ssl.truststore.password`
: The password for the trust store file.
  <br/>
  * Type: password
  * Importance: high

`connections.max.idle.ms`
: Close idle connections after the number of milliseconds specified by this config.
  <br/>
  * Type: long
  * Default: 540000
  * Importance: medium

`receive.buffer.bytes`
: The size of the TCP receive buffer (SO_RCVBUF) to use when reading data.
  <br/>
  * Type: int
  * Default: 32768
  * Importance: medium

`request.timeout.ms`
: The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.
  <br/>
  * Type: int
  * Default: 40000
  * Importance: medium

`sasl.kerberos.service.name`
: The Kerberos principal name that Kafka runs as. This can be defined either in Kafka’s JAAS config or in Kafka’s config.
  <br/>
  * Type: string
  * Importance: medium

`security.protocol`
: Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.
  <br/>
  * Type: string
  * Default: “PLAINTEXT”
  * Importance: medium

`send.buffer.bytes`
: The size of the TCP send buffer (SO_SNDBUF) to use when sending data.
  <br/>
  * Type: int
  * Default: 131072
  * Importance: medium

`ssl.enabled.protocols`
: The comma-separated list of protocols enabled for TLS connections. The default
  value is `TLSv1.2,TLSv1.3` when running with Java 11 or later, `TLSv1.2`
  otherwise. With the default value for Java 11 (`TLSv1.2,TLSv1.3`), Kafka
  clients and brokers prefer TLSv1.3 if both support it, and falls back to
  TLSv1.2 otherwise (assuming both support at least TLSv1.2).
  <br/>
  * Type: list
  * Default: `TLSv1.2,TLSv1.3`
  * Importance: medium

`ssl.keystore.type`
: The file format of the key store file. This is optional for client. Default value is JKS
  <br/>
  * Type: string
  * Default: “JKS”
  * Importance: medium

`ssl.protocol`
: The TLS protocol used to generate the SSLContext. The default is `TLSv1.3`
  when running with Java 11 or newer, `TLSv1.2` otherwise. This value should
  be fine for most use cases. Allowed values in recent JVMs are `TLSv1.2` and
  `TLSv1.3`. `TLS`, `TLSv1.1`, `SSL`, `SSLv2` and `SSLv3` might be
  supported in older JVMs, but their usage is discouraged due to known security
  vulnerabilities. With the default value for this configuration and `ssl.enabled.protocols`,
  clients downgrade to `TLSv1.2` if the server does not support `TLSv1.3`.
  If this configuration is set to `TLSv1.2`, clients do not use `TLSv1.3`,
  even if it is one of the values in `ssl.enabled.protocols` and the server
  only supports `TLSv1.3`.
  <br/>
  * Type: string
  * Default: `TLSv1.3`
  * Importance: medium

`ssl.provider`
: The name of the security provider used for TLS/SSL connections. Default value is the default security provider of the JVM.
  <br/>
  * Type: string
  * Importance: medium

`ssl.truststore.type`
: The file format of the trust store file. Default value is JKS.
  <br/>
  * Type: string
  * Default: “JKS”
  * Importance: medium

`worker.sync.timeout.ms`
: When the Worker is out of sync with other Workers and needs to resynchronize configurations, wait up to this amount of time before giving up, leaving the group, and waiting a backoff period before rejoining.
  <br/>
  * Type: int
  * Default: 3000
  * Importance: medium

`worker.unsync.backoff.ms`
: When the Worker is out of sync with other Workers and  fails to catch up within Worker.sync.timeout.ms, leave the Connect cluster for this long before rejoining.
  <br/>
  * Type: int
  * Default: 300000
  * Importance: medium

`client.id`
: An ID string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.
  <br/>
  * Type: string
  * Default: “”
  * Importance: low

`metadata.max.age.ms`
: The period of time in milliseconds after which you force a refresh of metadata even if you haven’t seen any partition leadership changes to proactively discover any new brokers or partitions.
  <br/>
  * Type: long
  * Default: 300000
  * Importance: low

`metric.reporters`
: A list of classes to use as metrics reporters. Implementing the `MetricReporter` interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.
  <br/>
  * Type: list
  * Default: []
  * Importance: low

`metrics.num.samples`
: The number of samples maintained to compute metrics.
  <br/>
  * Type: int
  * Default: 2
  * Importance: low

`metrics.sample.window.ms`
: The number of samples maintained to compute metrics.
  <br/>
  * Type: long
  * Default: 30000
  * Importance: low

`reconnect.backoff.ms`
: The amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all requests sent by the consumer to the broker.
  <br/>
  * Type: long
  * Default: 50
  * Importance: low

`retry.backoff.ms`
: The amount of time to wait before attempting to retry a failed fetch request to a given topic partition. This avoids repeated fetching-and-failing in a tight loop.
  <br/>
  * Type: long
  * Default: 100
  * Importance: low

`sasl.kerberos.kinit.cmd`
: Kerberos kinit command path. Default is /usr/bin/kinit
  <br/>
  * Type: string
  * Default: “/usr/bin/kinit”
  * Importance: low

`sasl.kerberos.min.time.before.relogin`
: Login thread sleep time between refresh attempts.
  <br/>
  * Type: long
  * Default: 60000
  * Importance: low

`sasl.kerberos.ticket.renew.jitter`
: Percentage of random jitter added to the renewal time.
  <br/>
  * Type: double
  * Default: 0.05
  * Importance: low

`sasl.kerberos.ticket.renew.window.factor`
: Login thread will sleep until the specified window factor of time from last refresh to ticket’s expiry has been reached, at which time it will try to renew the ticket.
  <br/>
  * Type: double
  * Default: 0.8
  * Importance: low

`ssl.cipher.suites`
: A list of cipher suites. This is a named combination of authentication,
  encryption, MAC, and key exchange algorithms used to negotiate the security
  settings for a network connection using TLS. By default, all the available
  cipher suites are supported.
  <br/>
  * Type: list
  * Importance: low

`ssl.endpoint.identification.algorithm`
: The endpoint identification algorithm to validate server hostname using server certificate.
  <br/>
  * Type: string
  * Importance: low

`ssl.keymanager.algorithm`
: The algorithm used by key manager factory for TLS/SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.
  <br/>
  * Type: string
  * Default: “SunX509”
  * Importance: low

`ssl.trustmanager.algorithm`
: The algorithm used by trust manager factory for TLS/SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.
  <br/>
  * Type: string
  * Default: “PKIX”
  * Importance: low

<a id="connect-worker-license-config"></a>

## Confluent Platform License Configuration

Starting in Confluent Platform 6.0, it is possible to put the Confluent license-related properties into the standalone and distributed worker configuration.
The Connect worker will then automatically inject these license-related properties into all of Confluent’s commercial connector configuration.
Then, the license-related properties can be left out of or removed from the connector configurations.

`confluent.license`
: Confluent issues enterprise license keys to each subscriber. The license key is text that you can copy and
  paste as the value for `confluent.license`. A trial license allows using the connector for a 30-day trial period. A developer license allows using the connector indefinitely for single-broker development environments.
  <br/>
  If you are a subscriber, contact Confluent Support for more information.
  <br/>
  * Type: string
  * Default: “”
  * Valid Values: Confluent Platform license
  * Importance: high

`confluent.topic.ssl.truststore.location`
: The location of the trust store file.
  <br/>
  * Type: string
  * Default: null
  * Importance: high

`confluent.topic.ssl.truststore.password`
: The password for the trust store file. If a password is not set access to the truststore is still available, but
  integrity checking is disabled.
  <br/>
  * Type: password
  * Default: null
  * Importance: high

`confluent.topic.ssl.keystore.location`
: The location of the key store file. This is optional for client and can be used for two-way authentication for client.
  <br/>
  * Type: string
  * Default: null
  * Importance: high

`confluent.topic.ssl.keystore.password`
: The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured.
  <br/>
  * Type: password
  * Default: null
  * Importance: high

`confluent.topic.ssl.key.password`
: The password of the private key in the key store file. This is optional for client.
  <br/>
  * Type: password
  * Default: null
  * Importance: high

`confluent.topic.security.protocol`
: Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.
  <br/>
  * Type: string
  * Default: “PLAINTEXT”
  * Importance: medium

### License topic configuration

A Confluent enterprise license is stored in the `_confluent-command` topic.
This topic is created by default and contains the license that corresponds to
the license key supplied through the `confluent.license` property. No public
keys are stored in Kafka topics.

The following describes how the default `_confluent-command` topic is
generated under different scenarios:

* A 30-day trial license is automatically generated for the `_confluent-command` topic if you do not add the `confluent.license` property or leave this property empty (for example, `confluent.license=`).
* Adding a valid license key (for example, `confluent.license=<valid-license-key>`) adds a valid license in the `_confluent-command` topic.

Here is an example of the minimal properties for development and testing.

You can change the name of the `_confluent-command` topic using the
`confluent.topic` property (for instance, if your environment has strict
naming conventions). The example below shows this change and the configured
Kafka bootstrap server.

```none
confluent.topic=foo_confluent-command
confluent.topic.bootstrap.servers=localhost:9092
```

The example above shows the minimally required bootstrap server property that
you can use for development and testing. For a production environment, you add
the normal producer, consumer, and topic configuration properties to the
connector properties, prefixed with `confluent.topic.`.

### License topic ACLs

The `_confluent-command` topic contains the license that corresponds to the
license key supplied through the `confluent.license` property. It is created
by default. Connectors that access this topic require the following ACLs
configured:

* CREATE and DESCRIBE on the resource cluster, if the connector needs to create the topic.
* DESCRIBE, READ, and WRITE on the `_confluent-command` topic.

  #### IMPORTANT
  You can also use DESCRIBE and READ without WRITE to restrict access to
  read-only for license topic ACLs. If a topic exists, the LicenseManager
  will not try to create the topic.

You can provide access either individually for each principal that will
use the license or use a [wildcard entry](/platform/current/kafka/authorization.html#acl-wildcard-principals) to
allow all clients. The following examples show commands that you can use to
configure ACLs for the resource cluster and `_confluent-command` topic.

1. Set a CREATE and DESCRIBE ACL on the resource cluster:
   ```none
   kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
   --add --allow-principal User:<principal> \
   --operation CREATE --operation DESCRIBE --cluster
   ```
2. Set a DESCRIBE, READ, and WRITE ACL on the `_confluent-command` topic:
   ```none
   kafka-acls --bootstrap-server localhost:9092 --command-config adminclient-configs.conf \
   --add --allow-principal User:<principal> \
   --operation DESCRIBE --operation READ --operation WRITE --topic _confluent-command
   ```

### Override Default Configuration Properties

You can override the replication factor using
`confluent.topic.replication.factor`.  For example, when using a Kafka cluster
as a destination with less than three brokers  (for development and testing) you
should set the `confluent.topic.replication.factor`  property to `1`.

You can override producer-specific properties by using the
`confluent.topic.producer.` prefix and consumer-specific properties by using
the `confluent.topic.consumer.` prefix.

You can use the defaults or customize the other properties as well. For example,
the `confluent.topic.client.id` property defaults to the name of the connector
with `-licensing` suffix. You can specify the configuration settings for
brokers that require TLS/SSL or SASL for client connections using this prefix.

You cannot override the cleanup policy of a topic because the topic always has a
single partition and is compacted. Also, do not specify serializers and
deserializers using this prefix; they are ignored if added.

<a id="connect-override-config"></a>

## Override the Worker Configuration

By default, source and sink connectors inherit their client configurations from
the worker configuration. Within the worker configuration, properties that have
a prefix of `producer.` or `consumer.` are used to create clients for all
source and sink connectors, respectively.

If you want to override producer or consumer properties for a specific
connector, enable client overrides in the worker configuration and then use
`producer.override.*` for a source connector configuration and
`consumer.override.*` for a sink connector configuration.

If you want to override admin properties for a specific connector, the process
is the same. You can include properties prefixed with `admin.override.*` in
your connector configuration and these properties will override any properties
derived from the worker configuration when creating admin clients for
connectors.

Source connectors use admin clients when you enable automatic topic creation.
Sink connectors, on the other hand, use admin clients when you enable a DLQ
topic.

#### IMPORTANT
- The Kafka Connect framework does not allow you to unset or set `null` for
  producer or consumer configuration properties. Instead, try to set the default
  callback handler at the connector level using the following configuration
  property:
  ```properties
  producer.override.sasl.login.callback.handler.class=org.apache.kafka.common.security.authenticator.AbstractLogin$DefaultLoginCallbackHandler
  ```
- For source connectors whose destination clusters uses SCRAM SASL mechanism, the default callback handler should not be set at connector level.
  Instead, set the producer configurations on the Kafka Connect framework. In such cases, change the distributed worker to point to the appropriate
  producer settings, for example:
  ```bash
  producer.bootstrap.servers"=x:9096,y:9096,z:9096
  producer.retry.backoff.ms= 500,
  producer.security.protocol=SASL_SSL
  producer.sasl.mechanism=SCRAM-SHA-512
  producer.sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username=\"######\" password=\"#####\";",
  producer.ssl.truststore.location = /var/ssl/private/kafka_connect.truststore.jks
  producer.ssl.truststore.password = ${securepass:/var/ssl/private/kafka-connect-security.properties:connect-distributed.properties/producer.ssl.truststore.password}
  ```

To enable per-connector configuration properties and override the default worker
properties, add the following `connector.client.config.override.policy`
configuration parameter to the worker properties file.

`connector.client.config.override.policy`
: The class name or alias implementation of ConnectorClientConfigOverridePolicy.
  This defines configurations that can be overridden by the connector. The
  default implementation is `All`. Other possible policies are `None` and
  `Principal`.
  <br/>
  * Type: string
  * Default: All
  * Valid Values: [All, None, Principal]
  * Importance: medium

When `connector.client.config.override.policy=All`, each connector that belongs to
the worker is allowed to override the worker configuration. This is implemented
by adding one of the following override prefixes to the source and sink
connector configurations:

* `producer.override.<source-configuration-property>`
* `consumer.override.<sink-configuration-property>`

### Examples

The following example shows a line added that overrides the default worker
`compression.type` property. After the connector configuration is updated, the
[Replicator](../../multi-dc-deployments/replicator/index.md#replicator-detail) connector will use gzip compression.

```json
{
  "name": "Replicator",
  "config": {
    "connector.class": "io.confluent.connect.replicator.ReplicatorSourceConnector",
    "topic.whitelist": "_schemas",
    "topic.rename.format": "\${topic}.replica",
    "key.converter": "io.confluent.connect.replicator.util.ByteArrayConverter",
    "value.converter": "io.confluent.connect.replicator.util.ByteArrayConverter",
    "src.kafka.bootstrap.servers": "srcKafka1:10091",
    "dest.kafka.bootstrap.servers": "destKafka1:11091",
    "tasks.max": "1",
    "producer.override.compression.type": "gzip",
    "confluent.topic.replication.factor": "1",
    "schema.subject.translator.class": "io.confluent.connect.replicator.schemas.DefaultSubjectTranslator",
    "schema.registry.topic": "_schemas",
    "schema.registry.url": "http://destSchemaregistry:8086"
  }
```

The following example shows a line added that overrides the default worker
`auto.offset.reset` property. After the connector configuration is updated,
the [Elasticsearch](https://docs.confluent.io/kafka-connectors/elasticsearch/current/)  connector will
use `latest` instead of the default connect worker property value
`earliest`.

```json
{
  "name": "Elasticsearch",
  "config": {
  "connector.class": "io.confluent.connect.elasticsearch.ElasticsearchSinkConnector",
  "topics": "orders",
  "consumer.override.auto.offset.reset": "latest",
  "tasks.max": 1,
  "connection.url": "http://elasticsearch:9200",
  "type.name": "type.name=kafkaconnect",
  "key.ignore": "true",
  "schema.ignore": "false",
  "transforms": "renameTopic",
  "transforms.renameTopic.type": "org.apache.kafka.connect.transforms.RegexRouter",
  "transforms.renameTopic.regex": "orders",
  "transforms.renameTopic.replacement": "orders-latest"
}'
```

When the worker override configuration property is set to `connector.client.config.override.policy=Principal`, each of the connectors can use a different service principal. The following example shows a sink connector service principal override when implementing [Role-Based Access Control (RBAC)](../rbac/connect-rbac-connectors.md#connect-rbac-connectors):

```none
consumer.override.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
   username="<username>" \
   password="<password>" \
   metadataServerUrls="<metadata_server_urls>";
```

When set to `All`, per-connector override capability includes overriding
the worker service principal in addition to other worker configuration
properties. When set to `Principal`, per-connector override capability is
restricted to service principal overrides only.

### Customize an Override

You may not want to use the worker override `All` to allow overriding all
connector configuration properties defined in the worker. While this is not
typical, you can create a custom override policy that allows you to limit the
connector configurations that can be overridden and their property values.

For example, if you need to create a custom policy for `batch.size` that
restricts the batch size to 1 MB, you would implement the
[ConnectorClientConfigOverridePolicy](/platform/current/connect/javadocs/javadoc/org/apache/kafka/connect/connector/policy/ConnectorClientConfigOverridePolicy.html) for this configuration property. This class implementation contains all the logic required to limit the list of configuration properties and their values.