# Apache Kafka Destination Config Reference


> Complete Rudder CLI reference for the Apache Kafka destination config keys, SSL and SASL, topic routing, Avro serialization, and secrets.



[Apache Kafka](https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/) is a streaming destination. RudderStack publishes each event as a message to a topic on your Kafka cluster — as JSON, or serialized with Avro — keyed by the event's `userId`, or `anonymousId` when `userId` is absent, so one user's events stay in the same partition.

In an Apache Kafka destination spec:

- `type: kafka`
- `definition_version: 1`

## Sample configuration

```yaml
version: rudder/v1
kind: destination
metadata:
  name: kafka-prod
spec:
  id: kafka-prod
  display_name: Kafka Production
  type: kafka
  definition_version: 1
  enabled: true
  config:
    host_name: "{{ .KAFKA_HOST_NAME }}"
    port: "9093"
    topic: rudder-events

    ssl_enabled: true
    use_sasl: true
    sasl_type: sha512
    username: "{{ .KAFKA_USERNAME }}"
    password: "{{ .KAFKA_PASSWORD }}"

    enable_multi_topic: true
    event_type_to_topic_map:
      - from: identify
        to: rudder-identifies
      - from: page
        to: rudder-pages
    event_to_topic_map:
      - from: Order Completed
        to: rudder-orders

    connection_mode:
      web: cloud
      cloud: cloud
    consent_management:
      web:
        - provider: oneTrust
          consents:
            - analytics
```

The above example connects over SSL with SCRAM-SHA-512 authentication — see [SSL and SASL](#ssl-and-sasl). It sends `identify` and `page` events and `Order Completed` to their own topics, and every other event to `topic` — see [Topic routing](#topic-routing). It omits the Avro and SSH tunnel keys.

## Config keys

`config` accepts only the keys listed below. The [shared config key rules](https://www.rudderstack.com/docs/rudder-cli/destination-types/#config-key-rules) cover unknown keys, defaults, and immutability.

### Connection

<div class="rs-ckeys">
<div class="rs-ckey" id="host_name">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">host_name</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Host name of your Kafka broker. To list several brokers, separate them with commas.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Each name consists of dot-separated labels of letters, digits, and hyphens, with no port and no scheme — <code>port</code> supplies the port.</li>
<li>Validation accepts a space after a comma, but RudderStack appends <code>:&lt;port&gt;</code> to each name exactly as written, so leave the spaces out.</li>
<li>Templates aren&rsquo;t accepted.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

<div class="rs-ckey" id="port">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">port</p>Required</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Port the brokers listen on. Every name in <code>host_name</code> uses it.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>A whole number from <code>1</code> to <code>65535</code>, written as a string. An unquoted number fails validation.</li>
<li>Templates aren&rsquo;t accepted.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">port: &#34;9093&#34;</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="topic">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">topic</p>Required</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Topic RudderStack publishes events to, unless an event is routed elsewhere — see <a href="#topic-routing" >Topic routing</a>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>1 to 249 characters: letters, digits, <code>.</code>, <code>_</code>, and <code>-</code>.</li>
<li>Templates aren&rsquo;t accepted.</li>
</ul>

</div>

</div>

</div>

### SSL and SASL

`ssl_enabled` and `use_sasl` decide which of the other keys here apply. SASL works only over SSL — RudderStack doesn't support SASL on a plaintext connection.

<div class="rs-ckeys">
<div class="rs-ckey" id="ssl_enabled">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">ssl_enabled</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Connect to the brokers over SSL.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>The dashboard defaults this field to <code>true</code>. Rudder CLI doesn&rsquo;t fill it in, and RudderStack treats an omitted value as <code>false</code>, so write <code>ssl_enabled: true</code> to connect over SSL.</li>
</ul>

</div>

</div>

<div class="rs-ckey" id="ca_certificate">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">ca_certificate</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  PEM-encoded CA certificate RudderStack verifies the brokers&rsquo; certificates against. When it&rsquo;s omitted, RudderStack trusts the system&rsquo;s CAs, which is enough for brokers whose certificates chain to a public CA.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Applies when <code>ssl_enabled</code> is <code>true</code>. Leave it unset otherwise.</li>
<li>Not validated locally.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <p>Write it as a YAML block scalar to keep its line breaks:</p>
<div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">ca_certificate: |
  -----BEGIN CERTIFICATE-----
  MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ
  ...
  -----END CERTIFICATE-----  </code></pre></div>
</div><p>See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/#does-my-kafka-server-require-client-authentication" >Does my Kafka server require client authentication?</a> for two-way SSL.</p>

</div>

</div>

<div class="rs-ckey" id="use_sasl">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">use_sasl</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Authenticate to the brokers with SASL, using <code>sasl_type</code>, <code>username</code>, and <code>password</code>. The dashboard calls this <strong>Enable SASL with SSL</strong>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Takes effect only when <code>ssl_enabled</code> is <code>true</code>. With SSL off, RudderStack ignores it and connects without authenticating, and Rudder CLI doesn&rsquo;t require <code>username</code>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/#does-rudderstack-support-sasl_plaintext-authentication" >Does RudderStack support <code>SASL_PLAINTEXT</code> authentication?</a>.
</div>

</div>

<div class="rs-ckey" id="sasl_type">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">sasl_type</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>plain</code>
  </p>
<p class="rs-ckey__field">
  Description:
  SASL mechanism RudderStack authenticates with.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>One of <code>plain</code> (PLAIN), <code>sha256</code> (SCRAM-SHA-256), or <code>sha512</code> (SCRAM-SHA-512).</li>
<li>Applies when <code>ssl_enabled</code> and <code>use_sasl</code> are both <code>true</code>. Leave it unset otherwise.</li>
<li>Templates aren&rsquo;t accepted.</li>
</ul>

</div>

</div>

<div class="rs-ckey" id="username">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">username</p>RequiredSecret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  SASL username.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Required when <code>ssl_enabled</code> and <code>use_sasl</code> are both <code>true</code>. Leave it unset otherwise.</li>
<li>1 to 32 characters: letters, digits, <code>_</code>, and <code>-</code>.</li>
<li>Templates aren&rsquo;t accepted.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

<div class="rs-ckey" id="password">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">password</p>Secret</div>
  <p class="rs-ckey__field">
    Type:
    <code>string</code>
  </p>
<p class="rs-ckey__field">
  Description:
  SASL password for <code>username</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Applies when <code>ssl_enabled</code> and <code>use_sasl</code> are both <code>true</code>. Rudder CLI doesn&rsquo;t require it.</li>
<li>At most 100 characters, and must not contain line breaks.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  Supply it as a <code>{{ .VAR }}</code> reference rather than a literal — see <a href="#secrets" >Secrets</a>.
</div>

</div>

</div>

### Topic routing

RudderStack picks each event's topic in this order:

1. The topic the event names itself, in `integrations.Kafka.topic` — see [Sending events to Kafka topics](https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/#sending-events-to-kafka-topics).
2. A matching entry in `event_type_to_topic_map` or `event_to_topic_map`, when `enable_multi_topic` is `true`.
3. `topic`.

<div class="rs-ckeys">
<div class="rs-ckey" id="enable_multi_topic">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">enable_multi_topic</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p><p class="rs-ckey__field">
    Default value:
    <code>false</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Route events to topics by event type and <code>track</code> event name, using <code>event_type_to_topic_map</code> and <code>event_to_topic_map</code>. When <code>false</code>, RudderStack ignores both mappings.
</p>

</div>

<div class="rs-ckey" id="event_type_to_topic_map">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">event_type_to_topic_map</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>array of objects</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps event types to topics. <code>track</code> events are routed by name instead, through <code>event_to_topic_map</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Applies when <code>enable_multi_topic</code> is <code>true</code>. Leave it unset otherwise.</li>
<li><code>from</code> — one of <code>identify</code>, <code>page</code>, <code>screen</code>, <code>group</code>, or <code>alias</code>. Templates aren&rsquo;t accepted.</li>
<li><code>to</code> — topic name. At most 100 characters, and must not contain line breaks. Unlike <code>topic</code>, its characters aren&rsquo;t checked. A <code>{{ path || fallback }}</code> template is accepted in place of a literal.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">event_type_to_topic_map:
  - from: identify
    to: rudder-identifies</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="event_to_topic_map">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">event_to_topic_map</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>array of objects</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps <code>track</code> event names to topics.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Applies when <code>enable_multi_topic</code> is <code>true</code>. Leave it unset otherwise.</li>
<li><code>from</code> — <code>track</code> event name, matched exactly, including case. At most 100 characters, and must not contain line breaks.</li>
<li><code>to</code> — topic name, on the same terms as in <code>event_type_to_topic_map</code>.</li>
<li>Both fields accept a <code>{{ path || fallback }}</code> template in place of a literal.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">event_to_topic_map:
  - from: Order Completed
    to: rudder-orders</code></pre></div>
</div>
</div>

</div>

</div>

### Avro serialization

<div class="rs-ckeys">
<div class="rs-ckey" id="convert_to_avro">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">convert_to_avro</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Serialize each event with Avro instead of publishing it as JSON. Each event selects its schema by ID, in <code>integrations.Kafka.schemaId</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>With this on, an event fails if it names no schema, names one that isn&rsquo;t in <code>avro_schemas</code>, or doesn&rsquo;t fit its schema. The schema has to cover every field the event carries.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  See <a href="https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/#serializing-data-using-avro" >Serializing data using Avro</a> for a sample event and its schema.
</div>

</div>

<div class="rs-ckey" id="avro_schemas">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">avro_schemas</p>Required</div>
  <p class="rs-ckey__field">
    Type:
    <code>array of objects</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Avro schemas events can be serialized with.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Required when <code>convert_to_avro</code> is <code>true</code>. Leave it unset otherwise.</li>
<li><code>schema_id</code> — ID an event names to select the schema.</li>
<li><code>schema</code> — the Avro schema, as a JSON string.</li>
<li>Both fields are required in every entry, even when <code>convert_to_avro</code> is <code>false</code>, and neither is validated further locally.</li>
<li>A schema that doesn&rsquo;t parse stops delivery to this destination entirely, not just for the events that use it.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">convert_to_avro: true
avro_schemas:
  - schema_id: &#34;1&#34;
    schema: &#39;{&#34;type&#34;: &#34;record&#34;, &#34;name&#34;: &#34;RudderEvent&#34;, &#34;fields&#34;: [...]}&#39;</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="embed_avro_schema_id">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">embed_avro_schema_id</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Prefix each Avro message with its schema ID, in the format Confluent Schema Registry consumers expect: a zero byte, then the ID as a 4-byte integer.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Applies when <code>convert_to_avro</code> is <code>true</code>. Leave it unset otherwise.</li>
<li>Every <code>schema_id</code> must then be a whole number — an event using a non-numeric ID fails.</li>
</ul>

</div>

</div>

</div>

### SSH tunnel

Both keys below are internal: the dashboard offers no SSH settings for Kafka. Rudder CLI accepts them so that a destination already set up to connect through an SSH tunnel keeps that setup on update — see [Some keys aren't in the dashboard](https://www.rudderstack.com/docs/rudder-cli/destination-types/#some-keys-arent-in-the-dashboard).

<div class="rs-ckeys">
<div class="rs-ckey" id="use_ssh">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">use_ssh</p>Internal</div>
  <p class="rs-ckey__field">
    Type:
    <code>boolean</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Connect to the brokers through an SSH tunnel via a bastion host.
</p>

</div>

<div class="rs-ckey" id="ssh">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">ssh</p>RequiredInternal</div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Bastion host connection details. RudderStack logs in with a private key it holds for this destination. <code>public_key</code> is the matching public key, which belongs in the bastion host&rsquo;s <code>authorized_keys</code>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>Required when <code>use_ssh</code> is <code>true</code>, with all four fields. Leave it unset otherwise.</li>
<li>A spec that sets <code>use_ssh: true</code> and omits any of the four fields fails validation.</li>
<li><code>host</code> — host name or IP address of the bastion host. Validation accepts a <code>host:port</code> form, but RudderStack appends <code>port</code> to this value, so leave the port out.</li>
<li><code>port</code> — SSH port of the bastion host, from <code>1</code> to <code>65535</code>, written as a string.</li>
<li><code>user</code> — user RudderStack logs in as. 1 to 32 characters: letters, digits, <code>_</code>, and <code>-</code>. <strong>Secret</strong> — see <a href="#secrets" >Secrets</a>.</li>
<li><code>public_key</code> — an <code>ssh-rsa</code>, <code>ssh-ed25519</code>, or <code>ssh-dss</code> public key, optionally followed by a <code>user@host</code> comment.</li>
<li>None of the four fields accepts a template.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">use_ssh: true
ssh:
  host: bastion.example.com
  port: &#34;22&#34;
  user: &#34;{{ .KAFKA_SSH_USER }}&#34;
  public_key: &#34;ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl rudderstack@bastion&#34;</code></pre></div>
</div>
</div>

</div>

</div>

### Per-source keys

Both keys are objects keyed by the local source type — the tokens listed under [Source types](#source-types). A key naming a source type this destination doesn't support fails validation.

<div class="rs-ckeys">
<div class="rs-ckey" id="connection_mode">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">connection_mode</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Maps each source type you connect to the mode its events reach Kafka in, using the modes in <a href="#source-types" >Source types</a>.
</p>

<div class="rs-ckey__notes">
  <p class="rs-ckey__field">Notes:</p>
  <ul>
<li>An entry is required for each source type you connect — see <a href="#connect-a-source" >Connect a source</a>.</li>
</ul>

</div>

<div class="rs-ckey__extra">
  <div class="rs-code">
  <div class="rs-code__head">yaml<button class="rs-code__copy" type="button">
      
      Copy
    </button>
  </div>
  <div class="highlight"><pre class="chroma"><code class="language-yaml" data-lang="yaml">connection_mode:
  web: cloud
  cloud: cloud</code></pre></div>
</div>
</div>

</div>

<div class="rs-ckey" id="consent_management">
  <div class="rs-ckey__title">
    <p class="rs-ckey__name">consent_management</p></div>
  <p class="rs-ckey__field">
    Type:
    <code>object</code>
  </p>
<p class="rs-ckey__field">
  Description:
  Consent provider configuration per source type. The entry shape, accepted providers, and the rules on <code>resolution_strategy</code> and <code>consents</code> are shared across all destination types — see <a href="https://www.rudderstack.com/docs/rudder-cli/destination-types/#consent-management" >Consent management</a>.
</p>

</div>

</div>

## Source types

Apache Kafka accepts events from these source types in the mentioned connection modes:

| Source type | Connection mode |
| :-----| :-----|
| `android` | `cloud` |
| `android_kotlin` | `cloud` |
| `ios` | `cloud` |
| `ios_swift` | `cloud` |
| `web` | `cloud` |
| `unity` | `cloud` |
| `cloud` | `cloud` |
| `react_native` | `cloud` |
| `flutter` | `cloud` |
| `cordova` | `cloud` |
| `warehouse` | `cloud` |

Every source type is `cloud` only — events reach Kafka from RudderStack's servers, never in device mode.

`warehouse` is the token a [Reverse ETL source](https://www.rudderstack.com/docs/sources/reverse-etl/) resolves to. Rudder CLI manages the destination’s `warehouse` entry — if the destination is connected to a Reverse ETL source, set `connection_mode.warehouse: cloud` in its spec, or `apply` removes it.

Rudder CLI can also declare the Reverse ETL connection itself, for the types listed under [Supported destinations](https://www.rudderstack.com/docs/rudder-cli/yaml-retl-connections/#supported-destinations) — see [Manage Reverse ETL Connections using Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/retl-connections/).

**Info:** The dashboard additionally offers Apache Kafka to AMP and Shopify sources. Rudder CLI doesn&#39;t manage those connections, so `amp` and `shopify` are invalid here.

## Connect a source

An event stream connection to this destination is checked against two rules at `validate` time.

**The source's type must be supported.** A source's type resolves to one of the tokens above before the check — a JavaScript source resolves to `web`, and webhook and server-side SDK sources resolve to `cloud`. Every type an event stream source can resolve to is supported here, so this check always passes.

**The destination config must carry a `connection_mode` entry for that source type.** This lives on the destination spec, not on the [connection spec](https://www.rudderstack.com/docs/rudder-cli/yaml-connections/). Without it:

```text
destination 'kafka-prod' config has no 'connection_mode' entry for source type 'web'
```

Apache Kafka needs no additional config keys to connect a source of any type.

## Secrets

`host_name`, `username`, `password`, and `ssh.user` are the secret keys. `username` and `password` apply only when `ssl_enabled` and `use_sasl` are both `true`, and `ssh.user` only when `use_ssh` is `true`. Write each one you use as a `{{ .VAR }}` reference and supply the value at apply time:

```yaml
config:
  host_name: "{{ .KAFKA_HOST_NAME }}"
  username: "{{ .KAFKA_USERNAME }}"
  password: "{{ .KAFKA_PASSWORD }}"
```

```bash
export RUDDER_KAFKA_HOST_NAME="..."
export RUDDER_KAFKA_USERNAME="..."
export RUDDER_KAFKA_PASSWORD="..."
rudder-cli apply

# or
rudder-cli apply --var-file secrets.vars.yaml
```

Note that:

- `rudder-cli import` writes only the secrets the API returns, as `{{ .VAR }}` references, and leaves the others out. Add any secret key it leaves out, then supply the variables before you apply — see [Secrets](https://www.rudderstack.com/docs/rudder-cli/destination-types/#secrets).
- `ca_certificate` and `ssh.public_key` aren't secrets — a CA certificate and a public key are public by design.

See [How to Use Variable Substitution in Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/variable-substitution/).

## Changes by release

<p>No changes since this type became available.</p>

For changes across every destination type, see [Destination Type Changes by Release](https://www.rudderstack.com/docs/rudder-cli/destination-types/changes/).

## See more

- [Apache Kafka Destination](https://www.rudderstack.com/docs/destinations/streaming-destinations/kafka/) for topic routing through the `integrations` object, Avro serialization, the partition key, and two-way SSL setup
- [Confluent Cloud Destination Config Reference](https://www.rudderstack.com/docs/rudder-cli/destination-types/confluent-cloud/) for a managed Kafka cluster on Confluent Cloud
- [Destination Type Reference for Rudder CLI](https://www.rudderstack.com/docs/rudder-cli/destination-types/) for the rules shared across destination types
- [Destination YAML Reference](https://www.rudderstack.com/docs/rudder-cli/yaml-destinations/) for the spec envelope