strimzi-kafka-operator Documentation

This is my commit message

Signed-off-by: John Doe <[email protected]>

git commit -s -m 'This is my commit message'

git commit --amend -s

cosign verify --certificate-identity-regexp='https://github.com/strimzi/.*' \
    --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
    quay.io/strimzi/operator:latest

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----

cosign verify --key strimzi.pub quay.io/strimzi/operator:latest --insecure-ignore-tlog=true

cosign verify-blob --bundle <SBOM-file>.bundle \
    --certificate-identity-regexp='https://github.com/strimzi/.*' \
    --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
    <SBOM-file>

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAET3OleLR7h0JqatY2KkECXhA9ZAkC
TRnbE23Wb5AzJPnpevvQ1QUEQQ5h/I4GobB7/jkGfqYkt6Ct5WOU2cc6HQ==
-----END PUBLIC KEY-----

cosign verify-blob --key cosign.pub --bundle <SBOM-file>.bundle --insecure-ignore-tlog=true <SBOM-file>

build-artifacts:
    name: build-artifacts
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: strimzi/github-actions/.github/actions/build/build-binaries@v2
        with:
          mvnArgs: "-B -DskipTests -Dmaven.javadoc.skip=true"

build-images:
    name: build-images
    strategy:
      matrix:
        architecture: [amd64, arm64]
    runs-on: cncf-ubuntu-2-8-arm
    steps:
      - uses: actions/checkout@v6
      - uses: strimzi/github-actions/.github/actions/build/build-containers@v2
        with:
          architecture: ${{ matrix.architecture }}

.github/tests/inputs/perf-report/
└── single-arch-both-operators/
    └── 2025-11-18-10-30-00/
        ├── topic-operator/    # matches PerformanceConstants.TOPIC_OPERATOR_PARSER = "topic-operator"
        └── user-operator/     # matches PerformanceConstants.USER_OPERATOR_PARSER = "user-operator"

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL
  seccompProfile:
    type: RuntimeDefault

kubectl apply -f https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.50.0/strimzi-crds-0.50.0.yaml

helm install my-strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator

helm delete my-strimzi-cluster-operator

helm install my-strimzi-cluster-operator --set replicas=2 oci://quay.io/strimzi-helm/strimzi-kafka-operator

2) Create the `strimzi-drain-cleaner` namespace:

3) Use `kubectl` to create a secret named `strimzi-drain-cleaner` with the `tls.crt` and `tls.key` files you generated:

This secret is used by the Strimzi Drain Cleaner deployment.
The resulting Secret should look similar to this:

4) With the installation files prepared, deploy Strimzi Drain Cleaner:

## Certificate renewals

Users are responsible for renewing the certificates before they expire.
The certificates can be renewed by just repeating the whole process and applying the updated YAML files.

---

### Overview (`packaging/examples/kafka/README.md`)

# KRaft examples

The examples in this directory demonstrate how you can use Kraft (ZooKeeper-less Apache Kafka) with Strimzi.
* The [`kafka-persistent.yaml`](kafka-persistent.yaml) deploys a Kafka cluster with one pool of _KRaft controller_ nodes and one pool of _KRaft broker_ nodes.
* The [`kafka-jbod.yaml`](kafka-jbod.yaml) deploys a Kafka cluster with one pool of _KRaft controller_ nodes and one pool of _KRaft broker_ nodes using multiple data volumes.
* The [`kafka-ephemeral.yaml`](kafka-ephemeral.yaml) deploys a Kafka cluster with one pool of _KRaft controller_ nodes, one pool of _KRaft broker_ nodes and ephemeral storage.
* The [`kafka-with-dual-role-nodes.yaml`](kafka-with-dual-role-nodes.yaml) deploys a Kafka cluster with one pool of KRaft nodes that share the _broker_ and _controller_ roles.
* The [`kafka-single-node.yaml`](kafka-single-node.yaml) deploys a Kafka cluster with a single Kafka node that has both _broker_ and _controller_ roles.

---

### Overview (`packaging/install/drain-cleaner/README.md`)

# Strimzi Drain Cleaner

Strimzi Drain Cleaner is a utility which helps with moving the Kafka pods deployed by [Strimzi](https://strimzi.io/) from Kubernetes nodes which are being drained.
It is useful if you want the Strimzi operator to move the pods instead of Kubernetes itself.
The advantage of this approach is that the Strimzi operator makes sure that no Kafka topics become under-replicated during the node draining.

For more information and installation guide, see [https://github.com/strimzi/drain-cleaner](https://github.com/strimzi/drain-cleaner).

---

### Overview (`packaging/examples/metrics/kube-state-metrics/README.md`)

# Kube-state-metrics

This folder contains examples of how Strimzi integrates [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) (KSM) for custom resources monitoring and demonstrates how they can be used.

[ConfigMap](./configmap.yaml):
* Contains the KSM configuration represented as `ConfigMap`

[PrometheusRules](./prometheus-rules.yaml)
* Contains the alerting based on metrics produced by KSM and collected by Prometheus
* Compatible with [Prometheus-Operator](https://github.com/prometheus-operator/prometheus-operator)

---

### Overview (`packaging/examples/metrics/strimzi-metrics-reporter/README.md`)

# Metrics configuration examples

The examples in this directory demonstrate how you can use configure metrics with Strimzi Metrics Reporter plugin.
There are also some Grafana dashboards that you can use with them.

---

### Overview (`packaging/examples/security/keycloak-authorization/README.md`)

# Keycloak authorization example

This folder contains an example `Kafka` custom resource configured for OAuth 2.0 token-based authorization using Keycloak.
The example resource is configured with:

* `custom` authentication using OAuth
* `custom` authorization based on the Keycloak authorizer

The folder also contains a Keycloak realm export to import into your Keycloak instance to support the example.

Full instructions for the example are available in the [Strimzi Documentation](https://strimzi.io/docs/operators/in-development/deploying.html#proc-oauth-authorization-keycloak-example_str).

- [kafka-authz-realm.json](./kafka-authz-realm.json)
  - The Keycloak realm export file
- [kafka-ephemeral-oauth-single-keycloak-authz.yaml](./kafka-ephemeral-oauth-single-keycloak-authz.yaml)
  - The Kafka CR that defines a single-node Kafka cluster with OAuth authentication and Keycloak authorization,
 using the `kafka-authz` realm. See [full example instructions](https://strimzi.io/docs/operators/in-development/configuring.html#proc-oauth-authorization-keycloak-example_str) for proper preparation and deployment.
- [kafka-ephemeral-oauth-single-keycloak-authz-metrics.yaml](./kafka-ephemeral-oauth-single-keycloak-authz-metrics.yaml)
  - The Kafka CR that defines a single-node Kafka cluster with OAuth authentication and Keycloak authorization,
 with included configuration for exporting the OAuth metrics using Prometheus JMX exporter.

More examples are available at the oauth module [example documentation](https://github.com/strimzi/strimzi-kafka-oauth/tree/main/examples).

---

### Overview (`packaging/helm-charts/helm3/strimzi-kafka-operator/README.md`)

# Strimzi: Apache Kafka on Kubernetes

Strimzi provides a way to run an [Apache Kafka®](https://kafka.apache.org) cluster on
[Kubernetes](https://kubernetes.io/) or [OpenShift](https://www.openshift.com/) in various deployment configurations.
See our [website](https://strimzi.io) for more details about the project.

**!!! IMPORTANT !!!**

**From Strimzi 1.3.0 on, we support only Kubernetes 1.32 and newer.**
Kubernetes 1.30 and 1.31 are not supported anymore.

**From Strimzi 1.2.0, the Helm Chart uses the default container security context that matches the [Restricted Kubernetes Pod Security Standard](https://kubernetes.io/docs/concepts/security/pod-security-standards/).**
```yaml
securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  capabilities:
 drop:
   - ALL
  seccompProfile:
 type: RuntimeDefault

kubectl apply -f https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.50.0/strimzi-crds-0.50.0.yaml

helm install my-strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator

helm delete my-strimzi-cluster-operator

helm install my-strimzi-cluster-operator --set replicas=2 oci://quay.io/strimzi-helm/strimzi-kafka-operator

2) Create the `strimzi-drain-cleaner` namespace:

3) Use `kubectl` to create a secret named `strimzi-drain-cleaner` with the `tls.crt` and `tls.key` files you generated:

This secret is used by the Strimzi Drain Cleaner deployment.
The resulting Secret should look similar to this:

4) With the installation files prepared, deploy Strimzi Drain Cleaner:

## Certificate renewals

Users are responsible for renewing the certificates before they expire.
The certificates can be renewed by just repeating the whole process and applying the updated YAML files.

---

### Overview (`systemtest/src/test/resources/upgrade/README.md`)

# Upgrade & downgrade tests

This short README describes how the upgrade and downgrade tests are configured and what needs to be updated to make the tests work.

We have Strimzi upgrade & downgrade tests (for both YAML and OLM installation types) focused mainly on upgrade/downgrade of Strimzi, 
if the components will be rolled correctly and if there will not be some issue with the Kafka cluster (and KafkaConnect) after Strimzi CO upgrade.
It also verifies that upgrade/downgrade from/to some feature gates is smooth and without issues.
The Strimzi upgrade scenario (covered in `KRaftStrimziUpgradeST`) is configurable in `BundleUpgrade.yaml` for YAML installation type and `OlmUpgrade.yaml` for OLM installation type (covered in `KRaftOlmUpgradeST`).
The downgrade scenario (covered in `KRaftStrimziDowngradeST`) is configurable in `BundleDowngrade.yaml`.

Other than Strimzi related tests, we have Kafka upgrade and downgrade tests.
These tests are not configurable in any way, we are taking the supported versions from `kafka-versions.yaml` through which we are doing the upgrade and downgrade scenarios.
The scenarios are covered inside `KRaftKafkaUpgradeDowngradeST`.

There are three situations when there are changes needed in the configuration YAML files:

## New Strimzi version

Once there is a new Strimzi version, all three YAML files should be updated accordingly.

Let's say that we have new Strimzi version - `0.47.0`:

- `BundleDowngrade.yaml`
  - `toVersion: 0.47.0`
  - `toExamples: strimzi-0.47.0`
  - `toUrl: https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.47.0/strimzi-0.47.0.zip`
  - in the `imagesAfterOperations`:
 - `kafka: strimzi/kafka:0.47.0-kafka-4.0.0` - the version of Kafka should reflect the latest supported version of Kafka from the Strimzi 0.47.0 version - also it should correspond to the version specified in `deployKafkaVersion`.
 - `topicOperator: strimzi/operator:0.47.0`
 - `userOperator: strimzi/operator:0.47.0`
  - based on graduation of feature gates you need to update `fromFeatureGates` and `toFeatureGates`
  - in case that new Strimzi version supports new Kafka version, you should update the `deployKafkaVersion` as well
- `BundleUpgrade.yaml`
  - `fromVersion: 0.47.0`
  - `fromExamples: strimzi-0.47.0`
  - `fromUrl: https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.47.0/strimzi-0.47.0.zip`
  - `fromKafkaVersionsUrl: https://raw.githubusercontent.com/strimzi/strimzi-kafka-operator/0.47.0/kafka-versions.yaml`
- `OlmUpgrade.yaml`
  - `fromVersion: 0.47.0`
  - `fromOlmChannelName: strimzi-0.47.x`
  - `fromExamples: strimzi-0.47.0`
  - `fromUrl: https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.47.0/strimzi-0.47.0.zip`
  - `fromKafkaVersionsUrl: https://raw.githubusercontent.com/strimzi/strimzi-kafka-operator/0.47.0/kafka-versions.yaml`

Technically, you can just replace the previous version of Strimzi to the new one - don't forget to change the OLM channel name in `fromOlmChannelName` when doing the search and replace with older version.

## New Kafka version

If you are just adding new Kafka version that is the latest one, you will need to change version of Kafka in `BundleUpgrade.yaml` - inside the `imagesAfterOperations.kafka`.
If it's just a patch release of an already supported minor Kafka version, no changes are needed.
Once a new version of Strimzi supports the new Kafka version, update the `deployKafkaVersion` field in `BundleDowngrade.yaml`.

## Removal of Kafka version

If there is Kafka version being removed from the support matrix of Strimzi, you have to change the `deployKafkaVersion` field in `BundleUpgrade.yaml`.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Bridge.KafkaBridgeConsumerSpec (`documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeConsumerSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures consumer options for the HTTP Bridge.

.Example HTTP Bridge consumer configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaBridgeApiVersion}
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  consumer:
 enabled: true
 timeoutSeconds: 60
 config:
   auto.offset.reset: earliest
   enable.auto.commit: true
 # ...
----

Use the `consumer.config` properties to configure Kafka options for the consumer as keys.

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the {ApacheKafkaConsumerConfig}.

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Kafka cluster bootstrap address
* Security (encryption, authentication, and authorization)
* Consumer group identifier

Properties with the following prefixes cannot be set:

* `bootstrap.servers`
* `group.id`
* `sasl.`
* `security.`
* `ssl.` 

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to HTTP Bridge, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]

IMPORTANT: The Cluster Operator does not validate keys or values in the `config` object.
If an invalid configuration is provided, the HTTP Bridge deployment might not start or might become unstable.
In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all HTTP Bridge nodes.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Bridge.KafkaBridgeHttpConfig (`documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeHttpConfig.adoc`)

:_mod-docs-content-type: CONCEPT

Configures HTTP access to a Kafka cluster for the HTTP Bridge.
The default HTTP configuration is for the HTTP Bridge to listen on port 8080.

.Example HTTP Bridge HTTP configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaBridgeApiVersion}
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  http:
 port: 8080
 cors:
   allowedOrigins: "https://strimzi.io"
   allowedMethods: "GET,POST,PUT,DELETE,OPTIONS,PATCH"
  # ...
----

As well as enabling HTTP access to a Kafka cluster, HTTP properties provide the capability to enable and define access control for the HTTP Bridge through Cross-Origin Resource Sharing (CORS).
CORS is a HTTP mechanism that allows browser access to selected resources from more than one origin.
To configure CORS, you define a list of allowed resource origins and HTTP access methods.
For the origins, you can use a URL or a Java regular expression.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Bridge.KafkaBridgeProducerSpec (`documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeProducerSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures producer options for the HTTP Bridge.

.Example HTTP Bridge producer configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaBridgeApiVersion}
kind: KafkaBridge
metadata:
  name: my-bridge
spec:
  # ...
  producer:
 enabled: true
 config:
   acks: 1
   delivery.timeout.ms: 300000
 # ...
----

Use the `producer.config` properties to configure Kafka options for the producer as keys.

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the {ApacheKafkaproducerConfig}.

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Kafka cluster bootstrap address
* Security (encryption, authentication, and authorization)
* Consumer group identifier

Properties with the following prefixes cannot be set:

* `bootstrap.servers`
* `sasl.`
* `security.`
* `ssl.` 

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to HTTP Bridge, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]

IMPORTANT: The Cluster Operator does not validate the keys or values of `config` properties.
If an invalid configuration is provided, the HTTP Bridge deployment might not start or might become unstable.
In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all HTTP Bridge nodes.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Bridge.KafkaBridgeSpec (`documentation/api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures a HTTP Bridge cluster.

Configuration options relate to:

* Kafka cluster bootstrap address
* Security (encryption, authentication, and authorization)
* Consumer configuration
* Producer configuration
* HTTP configuration

[id='property-http-bridge-logging-{context}']
= Logging

HTTP Bridge has its own preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger     | Description                                          | Default Level

| rootLogger | Default logger for all classes                       | INFO
| bridge     | All classes in the `io.strimzi.kafka.bridge` package | INFO
| healthy    | Uses `http.openapi.operation.healthy` endpoint       | WARN
| ready      | Uses `http.openapi.operation.ready` endpoint         | WARN
|===

You can configure log levels directly for these loggers.
For example:

[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
 type: inline
 loggers:
   rootLogger.level: INFO
   logger.ready.level: DEBUG
  # ...
----

You can also specify custom loggers for other operations:

* `createConsumer`
* `deleteConsumer`
* `subscribe`
* `unsubscribe`
* `poll`
* `assign`
* `commit`
* `send`
* `sendToPartition`
* `seekToBeginning`
* `seekToEnd`
* `seek`
* `openapi`

Each operation maps to an API endpoint,  defined according to the OpenAPI specification, and supports fine-grained logging via `http.openapi.operation.<operation_id>`.

For example, to set the logging level for the `send` operation logger:

[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
 type: inline
 loggers:
   logger.send.name: http.openapi.operation.send
   logger.send.level: DEBUG
  # ...
----

HTTP Bridge uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
 type: inline
 loggers:
   rootLogger.level: INFO
   # enabling DEBUG for send operation
   logger.send.name: http.openapi.operation.send
   logger.send.level: DEBUG
  # ...
----

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: KafkaBridge
spec:
  # ...
  logging:
 type: external
 valueFrom:
   configMapKeyRef:
     # name and key are mandatory
     name: customConfigMap
     key: log4j2.properties
  # ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.ClientTls (`documentation/api/io.strimzi.api.kafka.model.common.ClientTls.adoc`)

:_mod-docs-content-type: CONCEPT

Configures xref:con-common-configuration-trusted-certificates-reference[TLS trusted certificates] for connecting KafkaConnect, KafkaBridge, KafkaMirrorMaker2 to the cluster.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.EnvironmentVariableRack (`documentation/api/io.strimzi.api.kafka.model.common.EnvironmentVariableRack.adoc`)

:_mod-docs-content-type: CONCEPT

= Environment-variable-based rack awareness

Environment-variable-based rack awareness (`type: environment-variable`) is configured using `envVarName`.
`envVarName` identifies the environment variable that contains the name of the topology in its value.
You must configure this environment variable yourself, for example by setting it in the node pool `template` configuration or by applying a mutating webhook or similar tooling.

.Example `type: environment-variable` `rack` configuration for Kafka custom resource and per-node pool environment variables
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 rack:
   type: environment-variable
   envVarName: MY_RACK_ID
 # ...
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: zone-1
  labels:
 strimzi.io/cluster: my-cluster
spec:
  # ...
  template:
 kafkaContainer:
   env:
     - name: MY_RACK_ID
       value: zone-1
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: zone-2
  labels:
 strimzi.io/cluster: my-cluster
spec:
  # ...
  template:
 kafkaContainer:
   env:
     - name: MY_RACK_ID
       value: zone-2
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: zone-3
  labels:
 strimzi.io/cluster: my-cluster
spec:
  # ...
  template:
 kafkaContainer:
   env:
     - name: MY_RACK_ID
       value: zone-3
----

When rack awareness based on an environment variable is enabled, Strimzi does not add affinity rules.
You must configure your own  `affinity` or `topologySpreadConstraints` rules to make sure that nodes are properly distributed across racks.
For more information see link:{BookURLDeploying}#assembly-scheduling-str[Configuring pod scheduling^].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.TopologyLabelRack (`documentation/api/io.strimzi.api.kafka.model.common.TopologyLabelRack.adoc`)

:_mod-docs-content-type: CONCEPT

= Topology-label-based rack awareness

Topology-label-based rack awareness (`type: topology-label`) is configured through a `topologyKey`.
`topologyKey` identifies a label on Kubernetes worker nodes that contains the name of the topology in its value.
An example of such a label is `topology.kubernetes.io/zone` (or `failure-domain.beta.kubernetes.io/zone` on older Kubernetes versions), which contains the name of the availability zone in which the Kubernetes node runs.
You can configure your Kafka cluster to be aware of the _rack_ in which it runs and enable additional features such as spreading partition replicas across different racks or consuming messages from the closest replicas.

For more information about Kubernetes node labels, see {K8sWellKnownLabelsAnnotationsAndTaints}.
Consult your Kubernetes administrator regarding the node label that represents the zone or rack into which the node is deployed.

.Example `type: topology-label` `rack` configuration for Kafka custom resource
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 rack:
   type: topology-label
   topologyKey: topology.kubernetes.io/zone
 # ...
----

When rack awareness based on a topology label is enabled, Strimzi adds a node affinity rule to ensure Kafka nodes are scheduled on Kubernetes worker nodes that include the specified `topologyKey` label.
It does not configure additional rules to distribute nodes across racks or zones.
Depending on your exact Kubernetes and Kafka configurations, you should add additional `affinity` rules or configure `topologySpreadConstraints` for Kafka to make sure the nodes are properly distributed across as many racks as possible.
For more information see link:{BookURLDeploying}#assembly-scheduling-str[Configuring pod scheduling^].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationCustom (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationCustom.adoc`)

:_mod-docs-content-type: CONCEPT

To configure custom client authentication, set the `type` property to `custom`.
Custom client authentication allows you to use any type of Kafka-supported authentication mechanism.
This authentication option is especially useful with third-party Apache Kafka services, such as Amazon MSK, that require their own authentication mechanisms.

.Example custom client authentication configuration using the `AWS_MSK_IAM` authentication
[source,yaml,subs="attributes+"]
----
  authentication:
 type: custom
 sasl: true
 config:
   sasl.mechanism: AWS_MSK_IAM
   sasl.jaas.config: software.amazon.msk.auth.iam.IAMLoginModule required;
   sasl.client.callback.handler.class: software.amazon.msk.auth.iam.IAMClientCallbackHandler
----

The `config` section accepts only options that start with the prefixes `sasl.` and `ssl.keystore.`.
All other options are ignored.
To configure additional options, use the related properties of the Strimzi custom resource, such as `.spec.config` or `.spec.tls`.
The `security.protocol `setting is generated automatically from the `sasl` property (when you use `custom` authentication) and the `tls` configuration in the same Strimzi custom resource:

* SASL = True, TLS = True -> SASL_SSL
* SASL = False, TLS = True -> SSL
* SASL = True, TLS = False -> SASL_PLAINTEXT
* SASL = False, TLS = False -> PLAINTEXT

= Using secrets in custom authentication

If your custom authentication mechanism requires additional information from `Secret` or `ConfigMap` resources, use the link:{BookURLConfiguring}#con-common-configuration-volumes-reference[Additional Volumes^] feature to mount them into the operands.
Kafka configuration providers can be used to load them from the disk.

If the `config` section contains sensitive values such as passwords, tokens, or client secrets, do not embed them directly.
Use Kafka configuration providers to load sensitive values at runtime instead.
Strimzi includes the `KubernetesSecretConfigProvider` for loading values from Kubernetes `Secret` resources.
Other providers, such as the File or Directory providers, can also be used when the sensitive value is available on the filesystem.

Configure the config provider in the component's `spec.config` and reference secrets using the template syntax `${<config-provider-alias>:<namespace>/<secret-name>:<key>}`.

.Insecure: OAuth client secret as a literal value in sasl.jaas.config
[source,yaml]
----
authentication:
  type: custom
  sasl: true
  config:
 sasl.mechanism: OAUTHBEARER
 sasl.jaas.config: |
   org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
     oauth.client.id="my-client-id"
     oauth.client.secret="my-plaintext-client-secret"
     oauth.token.endpoint.uri="https://my-oauth-server/token";
 sasl.login.callback.handler.class: io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
----

.Secure: OAuth client secret loaded from a Kubernetes Secret via a config provider
[source,yaml,subs="attributes+"]
----
spec:
  config:
 config.providers: my-secrets-provider # <1>
 config.providers.my-secrets-provider.class: io.strimzi.kafka.KubernetesSecretConfigProvider # <2>
  # ...
  authentication:
 type: custom
 sasl: true
 config:
   sasl.mechanism: OAUTHBEARER
   sasl.jaas.config: |
     org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
       oauth.client.id="my-client-id"
       oauth.client.secret="${my-secrets-provider:mynamespace/my-oauth-secret:client-secret}" # <3>
       oauth.token.endpoint.uri="https://my-oauth-server/token";
   sasl.login.callback.handler.class: io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
----
<1> A user-chosen alias for the provider, used in template references.
<2> `KubernetesSecretConfigProvider` loads values from Kubernetes `Secret` resources at runtime.
<3> A config provider template reference. The `KubernetesSecretConfigProvider` resolves it to the actual secret value at runtime, so the sensitive value is never stored in plaintext in the component configuration.

The Secret can be in any namespace, as long as the service account has the required access rights.

IMPORTANT: You need to give the Kafka broker service account the access rights to the used Secret.
For more information on setting up access rights, see the link:{BookURLConfiguring}#assembly-loading-config-with-providers-str[Loading configuration values from external sources^] section.

= Using Kubernetes Service Account tokens for authentication

If the Kafka cluster has a listener that authenticates clients with Kubernetes Service Account tokens, you can connect the operand to it using `custom` authentication with the `OAUTHBEARER` SASL mechanism.
The operand reads the token from a file mounted into its pod and presents it to the Kafka cluster.
For information on how to configure such a listener, see the xref:type-KafkaListenerAuthenticationCustom-{context}[`KafkaListenerAuthenticationCustom` schema reference].

Strimzi mounts the Service Account token of the operand into the `/var/run/secrets/kubernetes.io/serviceaccount` directory.
This token is issued for the default audience of the Kubernetes API server.
If the Kafka listener requires a specific audience, use a projected Service Account token volume to mount a token issued for that audience instead.

.Example client authentication configuration using a projected Service Account token
[source,yaml,subs="attributes+"]
----
spec:
  authentication:
 type: custom
 sasl: true
 config:
   sasl.mechanism: OAUTHBEARER
   sasl.login.callback.handler.class: io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler
   sasl.jaas.config: |
     org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
       oauth.access.token.location="/mnt/auth-token/token";
  template:
 pod:
   volumes:
     - name: auth-token
       projected:
         sources:
           - serviceAccountToken:
               audience: my-internal-listener
               expirationSeconds: 3600
               path: token
 connectContainer:
   volumeMounts:
     - name: auth-token
       mountPath: /mnt/auth-token
----

In this configuration:

* `sasl.login.callback.handler.class` sets the Strimzi callback handler that passes the token to the Kafka cluster.
* `oauth.access.token.location` tells the Kafka client where to find the token file.
* The `projected` volume asks Kubernetes to issue a token for the Service Account of the operand pod with the `my-internal-listener` audience and to store it in a file named `token`.
* The volume is mounted at `/mnt/auth-token`, so the token is available in the `/mnt/auth-token/token` file.
Additional volumes can be mounted only into paths that start with `/mnt`.
For more information about additional volumes, see link:{BookURLConfiguring}#con-common-configuration-volumes-reference[Additional Volumes^].

The `connectContainer` name used in this example applies to `KafkaConnect` and `KafkaMirrorMaker2` resources.
For `KafkaBridge` resources, use `bridgeContainer` instead.

NOTE: A projected Service Account token is always issued for the Service Account used by the pod.
It cannot be used to obtain a token for a different Service Account.
Strimzi operands use a Service Account named after the component: `<connect_cluster_name>-connect` for Kafka Connect, `<mirror_maker_2_cluster_name>-mirrormaker2` for MirrorMaker 2, and `-bridge` for the HTTP Bridge.

= Using additional authentication plugins

Custom authentication mechanisms might require additional plugins for the operand.
You can add them using the link:{BookURLConfiguring}#con-common-configuration-volumes-reference[Additional Volumes^] feature.
Alternatively, you can build a custom container image.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationOAuth (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationOAuth.adoc`)

:_mod-docs-content-type: CONCEPT

To configure OAuth client authentication, set the `type` property to `oauth`.

OAuth authentication can be configured using one of the following options:

* Client ID and secret
* Client ID and refresh token
* Access token
* Username and password
* TLS

.Client ID and secret
You can configure the address of your authorization server in the `tokenEndpointUri` property together with the client ID and client secret used in authentication.
The OAuth client will connect to the OAuth server, authenticate using the client ID and secret and get an access token which it will use to authenticate with the Kafka broker.
In the `clientSecret` property, specify a link to a `Secret` containing the client secret.

.Example client ID and client secret configuration
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  clientId: my-client-id
  clientSecret:
 secretName: my-client-oauth-secret
 key: client-secret
----

Optionally, `scope` and `audience` can be specified if needed. `grantType` can also be specified for custom client credentials implementations.

.Client ID and refresh token
You can configure the address of your OAuth server in the `tokenEndpointUri` property together with the OAuth client ID and refresh token.
The OAuth client will connect to the OAuth server, authenticate using the client ID and refresh token and get an access token which it will use to authenticate with the Kafka broker.
In the `refreshToken` property, specify a link to a `Secret` containing the refresh token.

.Example client ID and refresh token configuration
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  clientId: my-client-id
  refreshToken:
 secretName: my-refresh-token-secret
 key: refresh-token
----

.Access token
You can configure the access token used for authentication with the Kafka broker directly.
In this case, you do not specify the `tokenEndpointUri`.
In the `accessToken` property, specify a link to a `Secret` containing the access token.
Alternatively, use `accessTokenLocation` property, and specify a path to the token file.

.Example access token only configuration
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  accessToken:
 secretName: my-access-token-secret
 key: access-token
----

.Example (service account) access token configuration specifying a mounted file
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  accessTokenLocation: `/var/run/secrets/kubernetes.io/serviceaccount/token`
----

.Username and password
OAuth username and password configuration uses the OAuth _Resource Owner Password Grant_ mechanism. The mechanism is deprecated, and is only supported to enable integration in environments where client credentials (ID and secret) cannot be used. You might need to use user accounts if your access management system does not support another approach or user accounts are required for authentication.

A typical approach is to create a special user account in your authorization server that represents your client application. You then give the account a long randomly generated password and a very limited set of permissions. For example, the account can only connect to your Kafka cluster, but is not allowed to use any other services or login to the user interface.

Consider using a refresh token mechanism first.

You can configure the address of your authorization server in the `tokenEndpointUri` property together with the client ID, username and the password used in authentication.
The OAuth client will connect to the OAuth server, authenticate using the username, the password, the client ID, and optionally even the client secret to obtain an access token which it will use to authenticate with the Kafka broker.

In the `passwordSecret` property, specify a link to a `Secret` containing the password.

Normally, you also have to configure a `clientId` using a public OAuth client. 
If you are using a confidential OAuth client, you also have to configure a `clientSecret`.

.Example username and password configuration with a public client
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  username: my-username
  passwordSecret:
 secretName: my-password-secret-name
 password: my-password-field-name
  clientId: my-public-client-id
----

.Example username and password configuration with a confidential client
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  username: my-username
  passwordSecret:
 secretName: my-password-secret-name
 password: my-password-field-name
  clientId: my-confidential-client-id
  clientSecret:
 secretName: my-confidential-client-oauth-secret
 key: client-secret
----

Optionally, `scope` and `audience` can be specified if needed.

.TLS
Accessing the OAuth server using the HTTPS protocol does not require any additional configuration as long as the TLS certificates used by it are signed by a trusted certification authority and its hostname is listed in the certificate.

If your OAuth server uses self-signed certificates or certificates signed by an untrusted certification authority, use the `tlsTrustedCertificates` property to specify the secrets containing them. 
The certificates must be in X.509 format.

.Example configuration specifying TLS certificates
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  clientId: my-client-id
  refreshToken:
 secretName: my-refresh-token-secret
 key: refresh-token
  tlsTrustedCertificates:
 - secretName: oauth-server-ca
   pattern: "*.crt"
----

The OAuth client will by default verify that the hostname of your OAuth server matches either the certificate subject or one of the alternative DNS names.
If it is not required, you can disable the hostname verification.

.Example configuration to disable TLS hostname verification
[source,yaml,subs=attributes+]
----
authentication:
  type: oauth
  tokenEndpointUri: https://<auth_server_address>/
  clientId: my-client-id
  refreshToken:
 secretName: my-refresh-token-secret
 key: refresh-token
  disableTlsHostnameVerification: true
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationPlain (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationPlain.adoc`)

:_mod-docs-content-type: CONCEPT

To configure SASL-based PLAIN authentication, set the `type` property to `plain`.
The SASL PLAIN authentication mechanism requires a username and password.

.An example SASL-based PLAIN client authentication configuration for Kafka Connect
[source,yaml,subs=attributes+]
----
authentication:
  type: plain
  username: my-connect-username
  passwordSecret:
 secretName: my-connect-secret-name
 password: my-password-field-name
----

WARNING: The SASL PLAIN mechanism will transfer the username and password across the network in cleartext.
Only use SASL PLAIN authentication if TLS encryption is enabled.

In the `passwordSecret` property, specify a link to a `Secret` containing the password.

You can use the secrets created by the User Operator.

If required, create a text file that contains the password, in cleartext, to use for authentication:

[source,shell,subs="+quotes"]
echo -n  > <my_password>.txt

You can then create a `Secret` from the text file, setting your own field name (key) for the password:

[source,shell,subs="+quotes"]
kubectl create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt

.Example secret for PLAIN client authentication for Kafka Connect
[source,yaml,subs="attributes+"]
----
apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-password-field-name: LFTIyFRFlMmU2N2Tm
----

The `secretName` property contains the name of the `Secret` and the `password` property contains the name of the key under which the password is stored inside the `Secret`.

IMPORTANT: Do not specify the actual password in the `password` property.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationScramSha256 (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationScramSha256.adoc`)

:_mod-docs-content-type: CONCEPT

To configure SASL-based SCRAM-SHA-256 authentication, set the `type` property to `scram-sha-256`.
The SCRAM-SHA-256 authentication mechanism requires a username and password.

.Example SASL-based SCRAM-SHA-256 client authentication configuration for Kafka Connect
[source,yaml,subs=attributes+]
----
authentication:
  type: scram-sha-256
  username: my-connect-username
  passwordSecret:
 secretName: my-connect-secret-name
 password: my-connect-password-field
----

In the `passwordSecret` property, specify a link to a `Secret` containing the password.

You can use the secrets created by the User Operator.

If required, you can create a text file that contains the password, in cleartext, to use for authentication:

[source,shell,subs="+quotes"]
echo -n  > <my_password>.txt

You can then create a `Secret` from the text file, setting your own field name (key) for the password:

[source,shell,subs="+quotes"]
kubectl create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt

.Example secret for SCRAM-SHA-256 client authentication for Kafka Connect
[source,yaml,subs="attributes+"]
----
apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm
----

The `secretName` property contains the name of the `Secret`, and the `password` property contains the name of the key under which the password is stored inside the `Secret`.

IMPORTANT: Do not specify the actual password in the `password` property.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationScramSha512 (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationScramSha512.adoc`)

:_mod-docs-content-type: CONCEPT

To configure SASL-based SCRAM-SHA-512 authentication, set the `type` property to `scram-sha-512`.
The SCRAM-SHA-512 authentication mechanism requires a username and password.

.Example SASL-based SCRAM-SHA-512 client authentication configuration for Kafka Connect
[source,yaml,subs=attributes+]
----
authentication:
  type: scram-sha-512
  username: my-connect-username
  passwordSecret:
 secretName: my-connect-secret-name
 password: my-connect-password-field
----

In the `passwordSecret` property, specify a link to a `Secret` containing the password.

You can use the secrets created by the User Operator.

If required, you can create a text file that contains the password, in cleartext, to use for authentication:

[source,shell,subs="+quotes"]
echo -n  > <my_password>.txt

You can then create a `Secret` from the text file, setting your own field name (key) for the password:

[source,shell,subs="+quotes"]
kubectl create secret generic <my-connect-secret-name> --from-file=<my_password_field_name>=./<my_password>.txt

.Example secret for SCRAM-SHA-512 client authentication for Kafka Connect
[source,yaml,subs="attributes+"]
----
apiVersion: v1
kind: Secret
metadata:
  name: my-connect-secret-name
type: Opaque
data:
  my-connect-password-field: LFTIyFRFlMmU2N2Tm
----

The `secretName` property contains the name of the `Secret`, and the `password` property contains the name of the key under which the password is stored inside the `Secret`.

IMPORTANT: Do not specify the actual password in the `password` property.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Authentication.KafkaClientAuthenticationTls (`documentation/api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationTls.adoc`)

:_mod-docs-content-type: CONCEPT

To configure mTLS authentication, set the `type` property to the value `tls`.
mTLS uses a TLS certificate to authenticate.

The certificate is specified in the `certificateAndKey` property and is always loaded from a Kubernetes secret.
In the secret, the certificate must be stored in X509 format under two different keys: public and private.

.Example mTLS configuration
[source,yaml,subs=attributes+]
----
authentication:
  type: tls
  certificateAndKey:
 secretName: my-secret
 certificate: my-public-tls-certificate-file.crt
 key: private.key
----

You can use the secrets created by the User Operator,
or you can create your own TLS certificate file, with the keys used for authentication, then create a `Secret` from the file:

[source,shell,subs=+quotes]
kubectl create secret generic <my_tls_secret> \
--from-file=<my_public_tls_certificate>.crt \
--from-file=<my_private_key>.key

.Example secret for mTLS client authentication
[source,yaml,subs="attributes+"]
----
apiVersion: v1
kind: Secret
metadata:
  name: my-tls-secret
type: Opaque
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJ...
  tls.key: LS0tLS1CRUdJTiBQUkl...
----

NOTE: mTLS authentication can only be used with TLS connections.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Jmx.KafkaJmxOptions (`documentation/api/io.strimzi.api.kafka.model.common.jmx.KafkaJmxOptions.adoc`)

:_mod-docs-content-type: CONCEPT

Configures JMX connection options.

Get JMX metrics from Kafka brokers, Kafka Connect, and MirrorMaker 2. by connecting to port 9999.
Use the `jmxOptions` property to configure a password-protected or an unprotected JMX port.
Using password protection prevents unauthorized pods from accessing the port.

You can then obtain metrics about the component.

For example, for each Kafka broker you can obtain bytes-per-second usage data from clients,
or the request rate of the network of the broker.

To enable security for the JMX port, set the `type` parameter in the `authentication` field to `password`.

.Example password-protected JMX configuration for Kafka brokers
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 jmxOptions:
   authentication:
     type: "password"
 # ...
----

You can then deploy a pod into a cluster and obtain JMX metrics using the headless
service by specifying which broker you want to address.

For example, to get JMX metrics from broker _0_ you specify:

[source,shell,subs="+quotes,attributes"]
----
"_CLUSTER-NAME_-kafka-0._CLUSTER-NAME_-kafka-brokers"
----

`_CLUSTER-NAME_-kafka-0` is name of the broker pod, and `_CLUSTER-NAME_-kafka-brokers` is the name of the headless service to return the IPs of the broker pods.

If the JMX port is secured, you can get the username and password by referencing them from the JMX Secret in the
deployment of your pod.

For an unprotected JMX port, use an empty object `{}` to open the JMX port on the headless service.
You deploy a pod and obtain metrics in the same way as for the protected port, but in this case any pod can read from the JMX port.

.Example open port JMX configuration for Kafka brokers
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 jmxOptions: {}
 # ...
----

NOTE: The `jmxOptions` configuration enables direct access to Java Management Extensions (JMX) from Kafka components. 
It is not required for the Prometheus JMX Exporter, which collects and converts JMX metrics to Prometheus metrics without direct JMX access.

[role="_additional-resources"]
.Additional resources

 * For more information on the Kafka component metrics exposed using JMX, see the {kafkaDoc}.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.ContainerTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.ContainerTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

You can set custom security context and environment variables for a container.

The environment variables are defined under the `env` property as a list of objects with `name` and `value` fields.
The following example shows two custom environment variables and a custom security context set for the Kafka broker containers:

[source,yaml,subs=attributes+]
----
# ...
template:
  kafkaContainer:
 env:
 - name: EXAMPLE_ENV_1
   value: example.env.one
 - name: EXAMPLE_ENV_2
   value: example.env.two
 securityContext:
   runAsUser: 2000
# ...
----

Environment variables prefixed with `KAFKA_` are internal to Strimzi and should be avoided.
If you set a custom environment variable that is already in use by Strimzi, it is ignored and a warning is recorded in the log.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.DeploymentTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.DeploymentTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

Use `deploymentStrategy` to specify the strategy used to replace old pods with new ones when deployment configuration changes.

Use one of the following values:

- `RollingUpdate`: Pods are restarted with zero downtime.
- `Recreate`: Pods are terminated before new ones are created.

Using the `Recreate` deployment strategy has the advantage of not requiring spare resources, but the disadvantage is the application downtime.

.Example showing the deployment strategy set to `Recreate`.
[source,yaml,subs="attributes+"]
----
# ...
template:
  deployment:
 deploymentStrategy: Recreate
# ...
----

This configuration change does not cause a rolling update.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.ExternalServiceTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.ExternalServiceTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

When exposing Kafka outside of Kubernetes using loadbalancers or node ports, you can use properties, in addition to labels and annotations, to customize how a Service is created.

.An example showing customized external services
[source,yaml,subs=attributes+]
----
# ...
template:
  externalBootstrapService:
 externalTrafficPolicy: Local
 loadBalancerSourceRanges:
   - 10.0.0.0/8
   - 88.208.76.87/32
  perPodService:
 externalTrafficPolicy: Local
 loadBalancerSourceRanges:
   - 10.0.0.0/8
   - 88.208.76.87/32
# ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.MetadataTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.MetadataTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

`Labels` and `Annotations` are used to identify and organize resources, and are configured in the `metadata` property.

For example:

[source,yaml,subs=attributes+]
----
# ...
template:
  pod:
 metadata:
   labels:
     label1: value1
     label2: value2
   annotations:
     annotation1: value1
     annotation2: value2
# ...
----

The `labels` and `annotations` fields can contain any labels or annotations that do not contain the reserved string `strimzi.io`.
Labels and annotations containing `strimzi.io` are used internally by Strimzi and cannot be configured.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.PodDisruptionBudgetTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.PodDisruptionBudgetTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

A `PodDisruptionBudget` is a Kubernetes resource that helps maintain high availability during planned maintenance or upgrades.
It defines the minimum number of pods that must remain available at all times.

Strimzi creates one `PodDisruptionBudget` per component:

* Kafka cluster
* Kafka Connect
* MirrorMaker 2
* HTTP Bridge
* Entity Operator
* Kafka Exporter
* Cruise Control

Each budget applies across all pods deployed for that component.

A single `PodDisruptionBudget` applies to all associated node pool pods managed by the `Kafka` resource.
This is true regardless of how many `StrimziPodSet` resources are created for that component.
Disruption limits are applied at the component level, not per node pool.

By default, only one pod can be unavailable at a time.
You can modify this limit using the `maxUnavailable` property.

`StrimziPodSet` custom resources are managed by a controller that does not use `maxUnavailable` directly.
Instead, the value is automatically converted to `minAvailable`, which serves the same purpose.

For example:

* If there are three broker pods and the `maxUnavailable` property is set to `1` in the `Kafka` resource, the `minAvailable` setting is `2`, allowing one pod to be unavailable.
* If there are three broker pods and the `maxUnavailable` property is set to `0` (zero), the `minAvailable` setting is `3`, requiring all three broker pods to be available and allowing zero pods to be unavailable.

The Entity Operator, Cruise Control, and Kafka Exporter run as `Deployment` resources, which support `maxUnavailable` directly.
For these components, the value is used as is and no conversion takes place.

.Example `PodDisruptionBudget` template configuration
[source,yaml,subs=attributes+]
----
# ...
template:
  podDisruptionBudget:
 metadata:
   labels:
     key1: label1
     key2: label2
   annotations:
     key1: label1
     key2: label2
 maxUnavailable: 1
# ...
----

.Custom disruption budget behavior

To define custom disruption budget behavior, disable automatic `PodDisruptionBudget` generation.
Set the `STRIMZI_POD_DISRUPTION_BUDGET_GENERATION` environment variable to `false` in the Cluster Operator.

You can then create your own `PodDisruptionBudget` resources.
For example, apply separate budgets to specific node pools using label selectors with `StrimziPodSet` resources.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.PodTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.PodTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the template for non-stateful pods.

.Example `PodTemplate` configuration
[source,yaml,subs=attributes+]
----
# ...
template:
  pod:
 metadata:
   labels:
     label1: value1
   annotations:
     anno1: value1
 imagePullSecrets:
   - name: my-docker-credentials
 securityContext:
   runAsUser: 1000001
   fsGroup: 0
 terminationGracePeriodSeconds: 120
 hostAliases:
   - ip: "192.168.1.86"
     hostnames:
     - "my-host-1"
     - "my-host-2"
 #...
----

Use the `hostAliases` property to a specify a list of hosts and IP addresses,
which are injected into the `/etc/hosts` file of the pod.
This configuration is especially useful for Kafka Connect or MirrorMaker when a connection outside of the cluster is also requested by users.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Common.Template.StatefulPodTemplate (`documentation/api/io.strimzi.api.kafka.model.common.template.StatefulPodTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the template for stateful pods (Kafka, Connect, and MirrorMaker 2 nodes).

.Example `StatefulPodTemplate` configuration
[source,yaml,subs=attributes+]
----
# ...
template:
  pod:
 metadata:
   labels:
     label1: value1
   annotations:
     anno1: value1
 imagePullSecrets:
   - name: my-docker-credentials
 securityContext:
   runAsUser: 1000001
   fsGroup: 0
 terminationGracePeriodSeconds: 120
 hostAliases:
   - ip: "192.168.1.86"
     hostnames:
     - "my-host-1"
     - "my-host-2"
 #...
----

Use the `hostAliases` property to specify a list of hosts and IP addresses,
which are injected into the `/etc/hosts` file of the pod.
This configuration is especially useful for Kafka Connect or MirrorMaker when a connection outside of the cluster is also requested by users.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Connect.KafkaConnectSpec (`documentation/api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures a Kafka Connect cluster.

[id='property-kafka-connect-internal-topics-grop-id-{context}']
= Group ID and internal topics

The group ID and the internal topics used by the Kafka Connect cluster are configured in the `.spec` section of the `KafkaConnect` resource

.Example group ID and internal topics configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  groupId: my-connect-group
  configStorageTopic: my-config-topic
  offsetStorageTopic: my-offset-topic
  statusStorageTopic: my-status-topic
  # ...
----

These fields are required.

If you do not set them, the following default values apply:

* `groupId` defaults to `connect-cluster`
* `configStorageTopic` defaults to `connect-cluster-configs`
* `offsetStorageTopic` defaults to `connect-cluster-offsets`
* `statusStorageTopic` defaults to `connect-cluster-status`

[id='property-kafka-connect-additional-configuration-{context}']
= Additional configuration

The `config` properties are one part of the overall configuration for the resource.
Use the `config` properties to configure additional Kafka Connect options as keys.

.Example Kafka Connect configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect
spec:
  # ...
  config:
 key.converter: org.apache.kafka.connect.json.JsonConverter
 value.converter: org.apache.kafka.connect.json.JsonConverter
 key.converter.schemas.enable: true
 value.converter.schemas.enable: true
 config.storage.replication.factor: 3
 offset.storage.replication.factor: 3
 status.storage.replication.factor: 3
  # ...
----

The values can be one of the following JSON types:

* String
* Number
* Boolean

Certain options have default values:

* `key.converter` with default value `org.apache.kafka.connect.json.JsonConverter`
* `value.converter` with default value `org.apache.kafka.connect.json.JsonConverter`

These options are automatically configured in case they are not present in the `KafkaConnect.spec.config` properties.

*Exceptions*

You can specify and configure the options listed in the link:{ApacheKafkaDocsBase}configuration/kafka-connect-configs/[Kafka Connect configuration documentation^].

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Kafka cluster bootstrap address
* Security (encryption, authentication, and authorization)
* Listener and REST interface configuration
* Plugin path configuration

Properties with the following prefixes cannot be set:

* `bootstrap.servers`
* `consumer.interceptor.classes`
* `listeners.`
* `plugin.path`
* `producer.interceptor.classes`
* `rest.`
* `sasl.`
* `security.`
* `ssl.`

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to Kafka Connect, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]

IMPORTANT: The Cluster Operator does not validate keys or values in the `config` object provided.
If an invalid configuration is provided, the Kafka Connect cluster might not start or might become unstable.
In this case, fix the configuration so that the Cluster Operator can roll out the new configuration to all Kafka Connect nodes.

[id='property-kafka-connect-logging-{context}']
= Logging

Kafka Connect has its own preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger      | Description                                                         | Default Level

| rootLogger  | Default logger for all classes                                      | INFO
| reflections | Logs classpath scanning and metadata discovery used to find plugins | ERROR
|===

Further loggers are added depending on the Kafka Connect plugins running.

Use a curl request to get a complete list of Kafka Connect loggers running from any Kafka broker pod:

[source,curl,subs=attributes+]
----
curl -s http://<connect-cluster-name>-connect-api:8083/admin/loggers/
----

Kafka Connect uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
spec:
  # ...
  logging:
 type: inline
 loggers:
   rootLogger.level: INFO
   logger.reflections.level: DEBUG
  # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`.
For example, to configure logging for Kafka Connect runtime classes inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.sourcetask.name: org.apache.kafka.connect.runtime.WorkerSourceTask # <1>
logger.sourcetask.level: TRACE # <2>
logger.sinktask.name: org.apache.kafka.connect.runtime.WorkerSinkTask # <3>
logger.sinktask.level: DEBUG # <4>
----
<1> Creates a logger for the runtime `WorkerSourceTask` class.
<2> Sets the logging level for `WorkerSourceTask`.
<3> Creates a logger for the runtime `WorkerSinkTask` class.
<4> Sets the logging level for `WorkerSinkTask`.

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
spec:
  # ...
  logging:
 type: external
 valueFrom:
   configMapKeyRef:
     # name and key are mandatory
     name: customConfigMap
     key: log4j2.properties
  # ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Connect.MountedPlugin (`documentation/api/io.strimzi.api.kafka.model.connect.MountedPlugin.adoc`)

:_mod-docs-content-type: CONCEPT

IMPORTANT: This feature requires Kubernetes support for the Image Volume feature.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Connect.Build.Build (`documentation/api/io.strimzi.api.kafka.model.connect.build.Build.adoc`)

:_mod-docs-content-type: CONCEPT

Configures additional connectors for Kafka Connect deployments.

= Configuring container registries

To build new container images with additional connector plugins, Strimzi requires a container registry where the images can be pushed to, stored, and pulled from.
Strimzi does not run its own container registry, so a registry must be provided.
Strimzi supports private container registries as well as public registries such as link:https://quay.io/[Quay^] or link:https://hub.docker.com//[Docker Hub^].
The container registry is configured in the `.spec.build.output` section of the `KafkaConnect` custom resource.
The `output` configuration, which is required, supports two types: `docker` and `imagestream`.

.Using Docker registry

To use a Docker registry, you have to specify the `type` as `docker`, and the `image` field with the full name of the new container image.
The full name must include:

* The address of the registry
* Port number (if listening on a non-standard port)
* The tag of the new container image

Example valid container image names:

* `docker.io/my-org/my-image/my-tag`
* `quay.io/my-org/my-image/my-tag`
* `image-registry.image-registry.svc:5000/myproject/kafka-connect-build:latest`

Each Kafka Connect deployment must use a separate image, which can mean different tags at the most basic level.

If the registry requires authentication, use the `pushSecret` to set a name of the Secret with the registry credentials.
For the Secret, use the `kubernetes.io/dockerconfigjson` type and a `.dockerconfigjson` file to contain the Docker credentials.
For more information on pulling an image from a private registry, see {K8sDockerSecret}.

[source,yaml,subs=attributes+,options="nowrap"]
.Example `output` configuration
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   type: docker # <1>
   image: my-registry.io/my-org/my-connect-cluster:latest # <2>
   pushSecret: my-registry-credentials # <3>
  #...
----
<1> (Required) Type of output used by Strimzi.
<2> (Required) Full name of the image used, including the repository and tag.
<3> (Optional) Name of the secret with the container registry credentials.

.Using OpenShift ImageStream

Instead of Docker, you can use OpenShift ImageStream to store a new container image.
The ImageStream has to be created manually before deploying Kafka Connect.
To use ImageStream, set the `type` to `imagestream`, and use the `image` property to specify the name of the ImageStream and the tag used.
For example, `my-connect-image-stream:latest`.

[source,yaml,subs=attributes+,options="nowrap"]
.Example `output` configuration
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   type: imagestream # <1>
   image: my-connect-build:latest # <2>
  #...
----
<1> (Required) Type of output used by Strimzi.
<2> (Required) Name of the ImageStream and tag.

= Configuring connector plugins 

Connector plugins are a set of files that define the implementation required to connect to certain types of external system.
The connector plugins required for a container image must be configured using the `.spec.build.plugins` property of the `KafkaConnect` custom resource.
Each connector plugin must have a name which is unique within the Kafka Connect deployment.
Additionally, the plugin artifacts must be listed.
These artifacts are downloaded by Strimzi, added to the new container image, and used in the Kafka Connect deployment.
The connector plugin artifacts can also include additional components, such as (de)serializers.
Each connector plugin is downloaded into a separate directory so that the different connectors and their dependencies are properly _sandboxed_.
Each plugin must be configured with at least one `artifact`.

[source,yaml,subs=attributes+,options="nowrap"]
.Example `plugins` configuration with two connector plugins
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   #...
 plugins: # <1>
   - name: connector-1
     artifacts:
       - type: tgz
         url: 
         sha512sum: <SHA-512_checksum_of_connector_1_artifact>
   - name: connector-2
     artifacts:
       - type: jar
         url: 
         sha512sum: <SHA-512_checksum_of_connector_2_artifact>
  #...
----
<1> (Required) List of connector plugins and their artifacts.

Strimzi supports the following types of artifacts:

--
* JAR files, which are downloaded and used directly
* TGZ archives, which are downloaded and unpacked
* ZIP archives, which are downloaded and unpacked
* Maven artifacts, which uses Maven coordinates
* Other artifacts, which are downloaded and used directly
--

IMPORTANT: Strimzi does not perform any security scanning of the downloaded artifacts.
For security reasons, you should first verify the artifacts manually, and configure the checksum verification to make sure the same artifact is used in the automated build and in the Kafka Connect deployment.

.Using JAR artifacts

JAR artifacts represent a JAR file that is downloaded and added to a container image.
To use a JAR artifacts, set the `type` property to `jar`, and specify the download location using the `url` property.

Additionally, you can specify a SHA-512 checksum of the artifact.
If specified, Strimzi will verify the checksum of the artifact while building the new container image.

[source,yaml,subs=attributes+,options="nowrap"]
.Example JAR artifact
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   #...
 plugins:
   - name: my-plugin
     artifacts:
       - type: jar # <1>
         url: https://my-domain.tld/my-jar.jar # <2>
         sha512sum: 589...ab4 # <3>
       - type: jar
         url: https://my-domain.tld/my-jar2.jar
  #...
----
<1> (Required) Type of artifact.
<2> (Required) URL from which the artifact is downloaded.
<3> (Optional) SHA-512 checksum to verify the artifact.

.Using TGZ artifacts

TGZ artifacts are used to download TAR archives that have been compressed using Gzip compression.
The TGZ artifact can contain the whole Kafka Connect connector, even when comprising multiple different files.
The TGZ artifact is automatically downloaded and unpacked by Strimzi while building the new container image.
To use TGZ artifacts, set the `type` property to `tgz`, and specify the download location using the `url` property.

Additionally, you can specify a SHA-512 checksum of the artifact.
If specified, Strimzi will verify the checksum before unpacking it and building the new container image.

[source,yaml,subs=attributes+,options="nowrap"]
.Example TGZ artifact
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   #...
 plugins:
   - name: my-plugin
     artifacts:
       - type: tgz # <1>
         url: https://my-domain.tld/my-connector-archive.tgz # <2>
         sha512sum: 158...jg10 # <3>
  #...
----
<1> (Required) Type of artifact.
<2> (Required) URL from which the archive is downloaded.
<3> (Optional) SHA-512 checksum to verify the artifact.

.Using ZIP artifacts

ZIP artifacts are used to download ZIP compressed archives.
Use ZIP artifacts in the same way as the TGZ artifacts described in the previous section.
The only difference is you specify `type: zip` instead of  `type: tgz`.

.Using Maven artifacts

`maven` artifacts are used to specify connector plugin artifacts as Maven coordinates.
The Maven coordinates identify plugin artifacts and dependencies so that they can be located and fetched from a Maven repository.

NOTE: The Maven repository must be accessible for the connector build process to add the artifacts to the container image.

[source,yaml,subs=attributes+,options="nowrap"]
.Example Maven artifact
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   #...
 plugins:
   - name: my-plugin
     artifacts:
       - type: maven # <1>
         group: <maven_group> # <3>
         artifact: <maven_artifact> # <4>
         version:  <maven_version_number> # <5>
  #...
----
<1> (Required) Type of artifact.
<2> (Optional) Maven repository to download the artifacts from. If you do not specify a repository, {MavenCentral} is used by default.
<3> (Required) Maven group ID.
<4> (Required) Maven artifact type.
<5> (Required) Maven version number.

.Using `other` artifacts

`other` artifacts represent any kind of file that is downloaded and added to a container image.
If you want to use a specific name for the artifact in the resulting container image, use the `fileName` field.
If a file name is not specified, the file is named based on the URL hash.

Additionally, you can specify a SHA-512 checksum of the artifact.
If specified, Strimzi will verify the checksum of the artifact while building the new container image.

[source,yaml,subs=attributes+,options="nowrap"]
.Example `other` artifact
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
metadata:
  name: my-connect-cluster
spec:
  #...
  build:
 output:
   #...
 plugins:
   - name: my-plugin
     artifacts:
       - type: other  # <1>
         url: https://my-domain.tld/my-other-file.ext  # <2>
         sha512sum: 589...ab4  # <3>
         fileName: name-the-file.ext  # <4>
  #...
----
<1> (Required) Type of artifact.
<2> (Required) URL from which the artifact is downloaded.
<3> (Optional) SHA-512 checksum to verify the artifact.
<4> (Optional) The name under which the file is stored in the resulting container image.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Connector.AutoRestart (`documentation/api/io.strimzi.api.kafka.model.connector.AutoRestart.adoc`)

:_mod-docs-content-type: CONCEPT

Configures automatic restarts for connectors and tasks that are in a `FAILED` state.

When enabled, a back-off algorithm applies the automatic restart to each failed connector and its tasks.
An incremental back-off interval is calculated using the formula `n * n + n` where `n` represents the number of previous restarts.
This interval is capped at a maximum of 60 minutes.
Consequently, a restart occurs immediately, followed by restarts after 2, 6, 12, 20, 30, 42, 56 minutes, and then at 60-minute intervals.
The restart counter is automatically reset once the connector has been running continuously for longer than the next backoff interval. 
For example, if the connector has restarted 4 times, it must run without errors for 20 minutes before the restart count resets to 0.
By default, Strimzi initiates restarts of the connector and its tasks indefinitely.
However, you can use the `maxRestarts` property to set a maximum on the number of restarts.
If `maxRestarts` is configured and the connector still fails even after the final restart attempt, you must then restart the connector manually.

For Kafka Connect connectors, use the `autoRestart` property of the `KafkaConnector` resource to enable automatic restarts of failed connectors and tasks.

.Enabling automatic restarts of failed connectors for Kafka Connect
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaConnectorApiVersion}
kind: KafkaConnector
metadata:
  name: my-source-connector
spec:
  autoRestart:
 enabled: true
----

If you prefer, you can also set a maximum limit on the number of restarts.

.Enabling automatic restarts of failed connectors for Kafka Connect with limited number of restarts
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaConnectorApiVersion}
kind: KafkaConnector
metadata:
  name: my-source-connector
spec:
  autoRestart:
 enabled: true
 maxRestarts: 10
----

For MirrorMaker 2, use the `autoRestart` property of connectors in the `KafkaMirrorMaker2` resource to enable automatic restarts of failed connectors and tasks.

.Enabling automatic restarts of failed connectors for MirrorMaker 2
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaMirrorMaker2ApiVersion}
kind: KafkaMirrorMaker2
metadata:
  name: my-mm2-cluster
spec:
  mirrors:
  - sourceConnector:
   autoRestart:
     enabled: true
   # ...
 checkpointConnector:
   autoRestart:
     enabled: true
   # ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.KafkaAuthorizationCustom (`documentation/api/io.strimzi.api.kafka.model.kafka.KafkaAuthorizationCustom.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the `Kafka` custom resource to use a custom authorizer and define Access Control Lists (ACLs).

ACLs allow you to define which users have access to which resources at a granular level.
Configure the `Kafka` custom resource to specify an authorizer class that implements the `org.apache.kafka.server.authorizer.Authorizer` interface to support custom ACLs.
Set the `type` property in the `authorization` section to the value `custom`, and configure a list of super users.
Super users are always allowed without querying ACL rules.
Add additional configuration for initializing the custom authorizer using `Kafka.spec.kafka.config`.

.Example `custom` authorization configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
 # ...
 authorization:
   type: custom
   authorizerClass: io.mycompany.CustomAuthorizer
   superUsers:
     - CN=user-1
     - user-2
     - CN=user-3
 # ...
 config:
   authorization.custom.property1=value1
   authorization.custom.property2=value2
 # ...
----

NOTE: The `super.user` configuration option in the `config` property in `Kafka.spec.kafka` is ignored.
Designate super users in the `authorization` property instead. 

= Adding custom authorizer JAR files to the container image

In addition to the `Kafka` custom resource configuration, the JAR files containing the custom authorizer class along with its dependencies must be available on the classpath of the Kafka broker.

You can add them by building Strimzi from the source-code.
The Strimzi build process provides a mechanism to add custom third-party libraries to the generated Kafka broker container image by adding them as dependencies in the `pom.xml` file under the `docker-images/artifacts/kafka-thirdparty-libs` directory.
The directory contains different folders for different Kafka versions. Choose the appropriate folder.
Before modifying the `pom.xml` file, the third-party library must be available in a Maven repository, and that Maven repository must be accessible to the Strimzi build process.

Alternatively, you can add the JARs to an existing Strimzi container image:

[source,subs="+quotes,attributes"]
----
FROM {DockerKafka}
USER root:root
COPY ./_my-authorizer_/ /opt/kafka/libs/
USER {DockerImageUser}
----

= Using custom authorizers with OAuth authentication

When using `oauth` authentication with a `groupsClaim` configuration to extract user group information from JWT tokens, group information can be used in custom authorization calls.
Groups are accessible through the `OAuthKafkaPrincipal` object during custom authorization calls, as follows:

[source, subs="attributes+"]
----
 public List<AuthorizationResult> authorize(AuthorizableRequestContext requestContext, List<Action> actions) {

     KafkaPrincipal principal = requestContext.principal();
     if (principal instanceof OAuthKafkaPrincipal) {
         OAuthKafkaPrincipal p = (OAuthKafkaPrincipal) principal;

         for (String group: p.getGroups()) {
             System.out.println("Group: " + group);
         }
     }
 }
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.KafkaAuthorizationSimple (`documentation/api/io.strimzi.api.kafka.model.kafka.KafkaAuthorizationSimple.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the `Kafka` custom resource to use simple authorization and define Access Control Lists (ACLs).

ACLs allow you to define which users have access to which resources at a granular level.

Strimzi uses Kafka's built-in `StandardAuthorizer` authorization plugin.

Set the `type` property in the `authorization` section to the value `simple`,
and configure a list of super users.
Super users are always allowed without querying ACL rules.

Access rules are configured for the `KafkaUser`, as described in the xref:type-AclRule-reference[ACLRule schema reference].

.Example `simple` authorization configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
 # ...
 authorization:
   type: simple
   superUsers:
     - CN=user-1
     - user-2
     - CN=user-3
 # ...
----

NOTE: The `super.user` configuration option in the `config` property in `Kafka.spec.kafka` is ignored.
Designate super users in the `authorization` property instead.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.KafkaClusterSpec (`documentation/api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures a Kafka cluster using the `Kafka` custom resource.

The `config` properties are one part of the overall configuration for the resource.
Use the `config` properties to configure Kafka broker options as keys.

.Example Kafka configuration
[source,yaml,subs="+attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 version: {DefaultKafkaVersion}
 metadataVersion: {DefaultKafkaMetadataVersion}
 # ...
 config:
   auto.create.topics.enable: "false"
   offsets.topic.replication.factor: 3
   transaction.state.log.replication.factor: 3
   transaction.state.log.min.isr: 2
   default.replication.factor: 3
   min.insync.replicas: 2
# ...
----

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the link:{ApacheKafkaDocsBase}configuration/broker-configs/[Kafka broker configuration documentation^].

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Security (encryption, authentication, and authorization)
* Listener configuration
* Broker ID configuration
* Configuration of log data directories
* Inter-broker communication

Properties with the following prefixes cannot be set:

* `advertised.`
* `authorizer.`
* `broker.`
* `controller`
* `cordoned.log.dirs`
* `cruise.control.metrics.reporter.bootstrap.`
* `cruise.control.metrics.topic`
* `host.name`
* `inter.broker.listener.name`
* `listener.`
* `listeners.`
* `log.dir`
* `password.`
* `port`
* `process.roles`
* `sasl.`
* `security.`
* `servers,node.id`
* `ssl.`
* `super.user`

NOTE: Strimzi supports only KRaft-based Kafka deployments. As a result, ZooKeeper-related configuration options are not supported.

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to Kafka, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]
* Cruise Control metrics properties:
** `cruise.control.metrics.topic.num.partitions`
** `cruise.control.metrics.topic.replication.factor`
** `cruise.control.metrics.topic.retention.ms`
** `cruise.control.metrics.topic.auto.create.retries`
** `cruise.control.metrics.topic.auto.create.timeout.ms`
** `cruise.control.metrics.topic.min.insync.replicas`
* Controller properties:
** `controller.quorum.election.backoff.max.ms`
** `controller.quorum.election.timeout.ms`
** `controller.quorum.fetch.timeout.ms`
* Listener properties (which are configured in the following format: `listener.name.listener1-9900.connections.max.reauth.ms` where `listener1-9900` is the listener name and port joined by `-`):
** `connections.max.reauth.ms`
** `max.connections`
** `max.connections.per.ip`
** `max.connections.per.ip.overrides`
** `max.connection.creation.rate`

[id='property-kafka-brokerRackInitImage-{context}']
= Configuring topology-label-based rack awareness and init container images

Rack awareness is enabled using the `rack` property.
When topology-label-based rack awareness is enabled, Kafka broker pods use an init container to collect labels from Kubernetes nodes.

NOTE: Environment-variable-based rack awareness does not require an init container, and therefore does not use the `brokerRackInitImage` image.

The container image for this init container can be specified using the `brokerRackInitImage` property. 
If the `brokerRackInitImage` field is not provided, the images used are prioritized as follows:

. Container image specified in `STRIMZI_DEFAULT_KAFKA_INIT_IMAGE` environment variable in the Cluster Operator configuration.
. `{DockerKafkaInit}` container image.

.Example `brokerRackInitImage` configuration
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 rack:
   type: topology-label
   topologyKey: topology.kubernetes.io/zone
 brokerRackInitImage: my-org/my-image:latest
 # ...
----

NOTE: Overriding container images is recommended only in special situations, such as when your network does not allow access to the container registry used by Strimzi. 
In such cases, you should either copy the Strimzi images or build them from the source. 
Be aware that if the configured image is not compatible with Strimzi images, it might not work properly.

[id='property-kafka-logging-{context}']
= Logging

Kafka has its own preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger              | Description                                              | Default Level

| rootLogger          | Default logger for all classes                           | INFO
| kafka               | Logs Kafka node classes                                  | INFO
| orgapachekafka      | Logs Kafka library classes                               | INFO
| requestlogger       | Logs client request details                              | WARN
| requestchannel      | Logs request handling in the broker                      | WARN
| controller          | Logs controller activity, such as leadership changes     | INFO
| logcleaner          | Logs log compaction and cleanup processes                | INFO
| statechange         | Logs broker and partition state transitions              | INFO
| authorizer          | Logs access control decisions                            | INFO
|===

Kafka uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  kafka:
 # ...
 logging:
   type: inline
   loggers:
     rootLogger.level: INFO
     logger.kafka.level: DEBUG 
     logger.logcleaner.level: DEBUG 
     logger.authorizer.level: TRACE
  # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
For example, to configure logging for OAuth components inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.oauth.name: io.strimzi.kafka.oauth # <1>
logger.oauth.level: DEBUG # <2>
----
<1> Creates a logger for the `io.strimzi.kafka.oauth` package.
<2> Sets the logging level for the OAuth package.

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
spec:
  # ...
  logging:
 type: external
 valueFrom:
   configMapKeyRef:
     # name and key are mandatory
     name: customConfigMap
     key: log4j2.properties
  # ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

[id='property-kafka-rack-awarness-{context}']
= Rack awareness

The `rack` option configures rack awareness.
A _rack_ can represent an availability zone, data center, or an actual rack in your data center.
The _rack_ can be configured in two different ways:

* Based on a topology label of the Kubernetes worker node
* Based on a user-configured environment variable

== Spreading partition replicas across racks

When rack awareness is configured, Strimzi will set `broker.rack` configuration for each Kafka broker.
The `broker.rack` configuration assigns a rack ID to each broker.
When `broker.rack` is configured, Kafka brokers will spread partition replicas across as many different racks as possible.
When replicas are spread across multiple racks, the probability that multiple replicas will fail at the same time is lower than if they would be in the same rack.
Spreading replicas improves resiliency, and is important for availability and reliability.
To enable rack awareness in Kafka, add the `rack` option to the `.spec.kafka` section of the `Kafka` custom resource as shown in the example below.

NOTE: The _rack_ in which brokers run can change when pods are deleted or restarted.
As a result, replicas that were running in different racks might then share the same rack.
Use Cruise Control and the `KafkaRebalance` resource and the `RackAwareGoal` to make sure that replicas remain distributed across different racks.

== Consuming messages from the closest replicas

Rack awareness can also be used in consumers to fetch data from the closest replica.
This is useful for reducing the load on your network when a Kafka cluster spans multiple datacenters and can also reduce costs when running Kafka in public clouds.
However, it can lead to increased latency.

In order to be able to consume from the closest replica, rack awareness has to be configured in the Kafka cluster, and the `RackAwareReplicaSelector` has to be enabled.
The replica selector plugin provides the logic that enables clients to consume from the nearest replica.
The default implementation uses `LeaderSelector` to always select the leader replica for the client.
Specify `RackAwareReplicaSelector` for the `replica.selector.class` to switch from the default implementation.

.Example `rack` configuration with enabled replica-aware selector
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
 rack:
   type: topology-label
   topologyKey: topology.kubernetes.io/zone
 config:
   # ...
   replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
 # ...
----

In addition to the Kafka broker configuration, you also need to specify the `client.rack` option in your consumers.
The `client.rack` option should specify the _rack ID_ in which the consumer is running.
`RackAwareReplicaSelector` associates matching `broker.rack` and `client.rack` IDs, to find the nearest replica and consume from it.
If there are multiple replicas in the same rack, `RackAwareReplicaSelector` always selects the most up-to-date replica.
If the rack ID is not specified, or if it cannot find a replica with the same rack ID, it will fall back to the leader replica.

.Example showing client consuming from replicas in the same availability zone
image::rack-config-availability-zones.png[consuming from replicas in the same availability zone]

You can also configure Kafka Connect, MirrorMaker 2 and HTTP Bridge so that connectors consume messages from the closest replicas.
You enable rack awareness in the `KafkaConnect`, `KafkaMirrorMaker2`, and `KafkaBridge` custom resources.
The configuration does does not set affinity rules, but you can also configure `affinity` or `topologySpreadConstraints`.
For more information see link:{BookURLDeploying}#assembly-scheduling-str[Configuring pod scheduling^].

When deploying Kafka Connect using Strimzi, you can use the `rack` section in the `KafkaConnect` custom resource to automatically configure the `client.rack` option.

.Example `rack` configuration for Kafka Connect
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaConnectApiVersion}
kind: KafkaConnect
# ...
spec:
  # ...
  rack:
 type: topology-label
 topologyKey: topology.kubernetes.io/zone
  # ...
----

When deploying MirrorMaker 2 using Strimzi, you can use the `rack` section in the `KafkaMirrorMaker2` custom resource to automatically configure the `client.rack` option.

.Example `rack` configuration for MirrorMaker 2
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaMirrorMaker2ApiVersion}
kind: KafkaMirrorMaker2
# ...
spec:
  # ...
  rack:
 type: topology-label
 topologyKey: topology.kubernetes.io/zone
  # ...
----

When deploying HTTP Bridge using Strimzi, you can use the `rack` section in the `KafkaBridge` custom resource to automatically configure the `client.rack` option.

.Example `rack` configuration for HTTP Bridge
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaBridgeApiVersion}
kind: KafkaBridge
# ...
spec:
  # ...
  rack:
 type: topology-label
 topologyKey: topology.kubernetes.io/zone
  # ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Cruisecontrol.CruiseControlSpec (`documentation/api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures a Cruise Control cluster.

Configuration options relate to:

* Goals configuration
* Capacity limits for resource distribution goals

The `config` properties are one part of the overall configuration for the resource.
Use the `config` properties to configure Cruise Control options as keys.

.Example Cruise Control configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 # ...
 config:
   # Note that `default.goals` (superset) must also include all `hard.goals` (subset)
   default.goals: >
     com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
     com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
   hard.goals: >
     com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal
   cpu.balance.threshold: 1.1
   metadata.max.age.ms: 300000
   send.buffer.bytes: 131072
   webserver.http.cors.enabled: true
   webserver.http.cors.origin: "*"
   webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type"
 # ...
----

The values can be one of the following JSON types:

* String
* Number
* Boolean

*Exceptions*

You can specify and configure the options listed in the {CruiseControlConfigDocs}.

However, Strimzi takes care of configuring and managing options related to the following, which cannot be changed:

* Security (encryption, authentication, and authorization)
* Connection to the Kafka cluster
* Client ID configuration
* Web server configuration
* Self healing

Properties with the following prefixes cannot be set:

* `bootstrap.servers`
* `capacity.config.file`
* `client.id`
* `failed.brokers.zk.path`
* `kafka.broker.failure.detection.enable`
* `metric.reporter.sampler.bootstrap.servers`
* `network.`
* `request.reason.required`
* `security.`
* `self.healing.`
* `ssl.`
* `topic.config.provider.class`
* `two.step.`
* `webserver.accesslog.`
* `webserver.api.urlprefix`
* `webserver.http.`
* `webserver.session.path`
* `zookeeper.`

If the `config` property contains an option that cannot be changed, it is disregarded, and a warning message is logged to the Cluster Operator log file.
All other supported options are forwarded to Cruise Control, including the following exceptions to the options configured by Strimzi:

* Any `ssl` configuration for xref:con-common-configuration-ssl-reference[supported TLS versions and cipher suites]
* Configuration for `webserver` properties to enable Cross-Origin Resource Sharing (CORS)

[id='property-cruise-control-config-cors-{context}']
= Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) is a HTTP mechanism for controlling access to REST APIs.
Restrictions can be on access methods or originating URLs of client applications.
You can enable CORS with Cruise Control using the `webserver.http.cors.enabled` property in the `config`.
When enabled, CORS permits read access to the Cruise Control REST API from applications that have different originating URLs than Strimzi.
This allows applications from specified origins to use `GET` requests to fetch information about the Kafka cluster through the Cruise Control API.
For example, applications can fetch information on the current cluster load or the most recent optimization proposal.
`POST` requests are not permitted.

NOTE: For more information on using CORS with Cruise Control, see {CruiseControlApiDocs}.

.Enabling CORS for Cruise Control

You enable and configure CORS in `Kafka.spec.cruiseControl.config`.
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 # ...
 config:
   webserver.http.cors.enabled: true # <1>
   webserver.http.cors.origin: "*" # <2>
   webserver.http.cors.exposeheaders: "User-Task-ID,Content-Type" # <3>

 # ...
----
<1> Enables CORS.
<2> Specifies permitted origins for the `Access-Control-Allow-Origin` HTTP response header. You can use a wildcard or specify a single origin as a URL. If you use a wildcard, a response is returned following requests from any origin.
<3> Exposes specified header names for the `Access-Control-Expose-Headers` HTTP response header. Applications in permitted origins can read responses with the specified headers.

= Cruise Control REST API security

The Cruise Control REST API is secured with HTTP Basic authentication and SSL to protect the cluster against potentially destructive Cruise Control operations, such as decommissioning Kafka brokers.
We recommend that Cruise Control in Strimzi is **only used with these settings enabled**.

However, it is possible to disable these settings by specifying the following Cruise Control configuration:

* To disable the built-in HTTP Basic authentication, set `webserver.security.enable` to `false`.
* To disable the built-in SSL encryption, disable encryption in the Cluster Security configuration.

.Cruise Control configuration to disable API authorization, authentication, and SSL
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 config:
   webserver.security.enable: false
# ...
----

[id='property-cruise-control-capacity-api-users-{context}']
= API users

With the necessary permissions, create REST API users to safely access a secured Cruise Control REST API directly.

This allows roles and permissions to be defined to allow advanced users and third-party applications to access the Cruise Control REST API without having to disable basic HTTP authentication.

The following use cases would benefit from accessing the Cruise Control API without disabling API security:

* Monitoring a Strimzi-managed Kafka cluster with the Cruise Control user interface.
* Gathering Cruise Control-specific statistical information not available through Strimzi or Cruise Control sensor metrics, such as detailed information surrounding cluster and partition load and user tasks.
* Debugging Cruise Control in a secured environment.

Cruise Control reads authentication credentials for API users in Jetty's `HashLoginService` file format.

Standard Cruise Control `USER` and `VIEWER` roles are supported.

* `USER` has access to all the `GET` endpoints except `bootstrap` and `train`.
* `VIEWER` has access to `kafka_cluster_state`, `user_tasks`, and `review_board` endpoints.

In this example, we define two custom API users in the supported format in a text file called `cruise-control-auth.txt`:

[source]
----
userOne: passwordOne, USER
userTwo: passwordTwo, VIEWER
----

Then, use this file to create a secret with the following command:

[source]
----
kubectl create secret generic cruise-control-api-users-secret  --from-file=cruise-control-auth.txt=cruise-control-auth.txt
----

Next, we reference the secret in the `spec.cruiseControl.apiUsers` section of the Kafka resource:

.Example Cruise Control apiUsers configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 # ...
 apiUsers:
   type: hashLoginService
   valueFrom:
     secretKeyRef:
       name: cruise-control-api-users-secret
       key: cruise-control-auth.txt
  ...
----

Strimzi then decodes and uses the contents of this secret to populate Cruise Control's API authentication credentials file.

[id='property-cruise-control-broker-capacity-{context}']
= Configuring capacity limits

Cruise Control uses capacity limits to determine if optimization goals for resource capacity limits are being broken.
There are four goals of this type:

* `DiskCapacityGoal`            - Disk utilization capacity
* `CpuCapacityGoal`             - CPU utilization capacity
* `NetworkInboundCapacityGoal`  - Network inbound utilization capacity
* `NetworkOutboundCapacityGoal` - Network outbound utilization capacity

You specify capacity limits for Kafka broker resources in the `brokerCapacity` property in `Kafka.spec.cruiseControl` .
They are enabled by default and you can change their default values.
Capacity limits can be set for the following broker resources:

* `cpu`             - CPU resource in millicores or CPU cores (Default: 1)
* `inboundNetwork`  - Inbound network throughput in byte units per second (Default: 10000KiB/s)
* `outboundNetwork` - Outbound network throughput in byte units per second (Default: 10000KiB/s)

For network throughput, use an integer value with standard Kubernetes byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second.

NOTE: Disk and CPU capacity limits are automatically generated by Strimzi, so you do not need to set them.
In order to guarantee accurate rebalance proposals when using CPU goals, you can set CPU requests equal to CPU limits in `KafkaNodePool.spec.resources`.
That way, all CPU resources are reserved upfront and are always available.
This configuration allows Cruise Control to properly evaluate the CPU utilization when preparing the rebalance proposals based on CPU goals.
In cases where you cannot set CPU requests equal to CPU limits in `KafkaNodePool.spec.resources`, you can set the CPU capacity manually for the same accuracy.

.Example Cruise Control brokerCapacity configuration using bibyte units
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 # ...
 brokerCapacity:
   cpu: "2"
   inboundNetwork: 10000KiB/s
   outboundNetwork: 10000KiB/s
 # ...
----

[id='property-cruise-control-capacity-overrides-{context}']
= Configuring capacity overrides

Brokers might be running on nodes with heterogeneous network or CPU resources.
If that's the case, specify `overrides` that set the network capacity and CPU limits for each broker.
The overrides ensure an accurate rebalance between the brokers.
Override capacity limits can be set for the following broker resources:

* `cpu`             - CPU resource in millicores or CPU cores (Default: 1)
* `inboundNetwork`  - Inbound network throughput in byte units per second (Default: 10000KiB/s)
* `outboundNetwork` - Outbound network throughput in byte units per second (Default: 10000KiB/s)

.An example of Cruise Control capacity overrides configuration using bibyte units
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
 # ...
 brokerCapacity:
   cpu: "1"
   inboundNetwork: 10000KiB/s
   outboundNetwork: 10000KiB/s
   overrides:
   - brokers: [0]
     cpu: "2.755"
     inboundNetwork: 20000KiB/s
     outboundNetwork: 20000KiB/s
   - brokers: [1, 2]
     cpu: 3000m
     inboundNetwork: 30000KiB/s
     outboundNetwork: 30000KiB/s
----

CPU capacity is determined using configuration values in the following order of precedence, with the highest priority first:

. `Kafka.spec.cruiseControl.brokerCapacity.overrides.cpu` that define custom CPU capacity limits for individual brokers
. `Kafka.cruiseControl.brokerCapacity.cpu` that defines custom CPU capacity limits for all brokers in the kafka cluster
. `KafkaNodePool.spec.resources.requests.cpu` that defines the CPU resources that are reserved for each broker in the Kafka cluster.
. `KafkaNodePool.spec.resources.limits.cpu` that defines the maximum CPU resources that can be consumed by each broker in the Kafka cluster.

This order of precedence is the sequence in which different configuration values are considered when determining the actual capacity limit for a Kafka broker. 
For example, broker-specific overrides take precedence over capacity limits for all brokers.
If none of the CPU capacity configurations are specified, the default CPU capacity for a Kafka broker is set to 1 CPU core. 

For more information, refer to the xref:type-BrokerCapacity-reference[BrokerCapacity schema reference].

[id='property-cruise-control-logging-{context}']
= Logging

Cruise Control has its own preconfigured logger:

[cols="1m,2,1",options="header"]
|===
| Logger     | Description                        | Default Level

| rootLogger | Default logger for all classes     | INFO
|===

Cruise Control uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
# ...
spec:
  cruiseControl:
 # ...
 logging:
   type: inline
   loggers:
     rootLogger.level: INFO
 # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
For example, to configure more detailed logging for Cruise Control inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.exec.name: com.linkedin.kafka.cruisecontrol.executor.Executor # <1>
logger.exec.level: TRACE # <2>
logger.go.name: com.linkedin.kafka.cruisecontrol.analyzer.GoalOptimizer # <3>
logger.go.level: DEBUG # <4>
----
<1> Creates a logger for the Cruise Control `Executor` class.
<2> Sets the logging level for the `Executor` class.
<3> Creates a logger for the Cruise Control `GoalOptimizer` class.
<4> Sets the logging level for the `GoalOptimizer` class.

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
# ...
spec:
  cruiseControl:
 # ...
 logging:
   type: external
   valueFrom:
     configMapKeyRef:
       # name and key are mandatory
       name: customConfigMap
       key: log4j2.properties
 # ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Entityoperator.EntityTopicOperatorSpec (`documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the Topic Operator.

[id='property-topic-operator-logging-{context}']
= Logging

The Topic Operator has its own preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger     | Description                    | Default Level

| rootLogger | Default logger for all classes | INFO
| jetty      | Logs HTTP server activity      | INFO
|===

The Topic Operator uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
  entityOperator:
 # ...
 topicOperator:
   watchedNamespace: my-topic-namespace
   reconciliationIntervalMs: 60000
   logging:
     type: inline
     loggers:
       rootLogger.level: INFO
       logger.jetty.level: WARN
  # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
For example, to configure more detailed logging for the Topic Operator inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.top.name: io.strimzi.operator.topic # <1>
logger.top.level: DEBUG # <2> 
logger.toc.name: io.strimzi.operator.topic.TopicOperator # <3>
logger.toc.level: TRACE # <4>
----
<1> Creates a logger for the `topic` package.
<2> Sets the logging level for the `topic` package.
<3> Creates a logger for the `TopicOperator` class.
<4> Sets the logging level for the `TopicOperator` class.

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
  entityOperator:
 # ...
 topicOperator:
   watchedNamespace: my-topic-namespace
   reconciliationIntervalMs: 60000
   logging:
     type: external
     valueFrom:
       configMapKeyRef:
         # name and key are mandatory
         name: customConfigMap
         key: log4j2.properties
  # ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Entityoperator.EntityUserOperatorSpec (`documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the User Operator.

[id='property-user-operator-logging-{context}']
= Logging

The User Operator has its own preconfigured loggers:

[cols="1m,2,1",options="header"]
|===
| Logger     | Description                    | Default Level

| rootLogger | Default logger for all classes | INFO
| jetty      | Logs HTTP server activity      | INFO
|===

The User Operator uses the Apache `log4j2` logger implementation.
Use the `logging` property to configure loggers and logger levels.

You can set log levels using either the `inline` or `external` logging configuration types.

Specify loggers and levels directly in the custom resource for inline configuration:

.Example inline logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
  entityOperator:
 # ...
 userOperator:
   watchedNamespace: my-topic-namespace
   reconciliationIntervalMs: 60000
   logging:
     type: inline
     loggers:
       rootLogger.level: INFO
       logger.jetty.level: WARN  
  # ...
----

You can define additional loggers by specifying the full class or package name using `logger.<name>.name`. 
For example, to configure more detailed logging for the User Operator inline:

.Example custom inline loggers
[source,yaml]
----
# ...
logger.uop.name: io.strimzi.operator.user # <1>
logger.uop.level: DEBUG # <2> 
logger.abstractcache.name: io.strimzi.operator.user.operator.cache.AbstractCache # <3>
logger.abstractcache.level: TRACE # <4>     
----
<1> Creates a logger for the `user` package.
<2> Sets the logging level for the `user` package.
<3> Creates a logger for the `AbstractCache` class.
<4> Sets the logging level for the `AbstractCache` class. 

Alternatively, you can reference an external `ConfigMap` containing a complete `log4j2.properties` file that defines your own log4j2 configuration, including loggers, appenders, and layout configuration:

.Example external logging configuration
[source,yaml,subs="+quotes,attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 # ...
  entityOperator:
 # ...
 userOperator:
   watchedNamespace: my-topic-namespace
   reconciliationIntervalMs: 60000
   logging:
     type: external
     valueFrom:
       configMapKeyRef:
         # name and key are mandatory
         name: customConfigMap
         key: log4j2.properties
# ...
----

.Garbage collector (GC)

Garbage collector logging can also be enabled (or disabled) using the xref:con-common-configuration-garbage-collection-reference[`jvmOptions` property].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Entityoperator.TlsSidecar (`documentation/api/io.strimzi.api.kafka.model.kafka.entityoperator.TlsSidecar.adoc`)

:_mod-docs-content-type: CONCEPT

The TLS sidecar type is not used anymore.
If set, it will be ignored

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Listener.GenericKafkaListener (`documentation/api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListener.adoc`)

:_mod-docs-content-type: CONCEPT

Configures listeners to connect to Kafka brokers within and outside Kubernetes.

Configure Kafka broker listeners using the `listeners` property in the `Kafka` resource.
Listeners are defined as an array.

.Example `Kafka` resource showing listener configuration
[source,yaml,subs="+attributes"]
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 #...
 listeners:
   - name: plain
     port: 9092
     type: internal
     tls: false
   - name: tls
     port: 9093
     type: internal
     tls: true
     authentication:
       type: tls
   - name: external1
     port: 9094
     type: route
     tls: true
   - name: external2
     port: 9095
     type: ingress
     tls: true
     authentication:
       type: tls
     configuration:
       bootstrap:
         host: bootstrap.myingress.com
       brokers:
       - broker: 0
         host: broker-0.myingress.com
       - broker: 1
         host: broker-1.myingress.com
       - broker: 2
         host: broker-2.myingress.com
 #...
----

The name and port must be unique within the Kafka cluster.
By specifying a unique name and port for each listener, you can configure multiple listeners.
The name can be up to 25 characters long, comprising lower-case letters and numbers.

[id='property-listener-port-{context}']
= Specifying a port number

The port number is the port used in the Kafka cluster, which might not be the same port used for access by a client.

* `loadbalancer` listeners use the specified port number, as do `internal` and `cluster-ip` listeners
* `ingress` and `route` listeners use port 443 for access
* `nodeport` listeners use the port number assigned by Kubernetes

For client connection, use the address and port for the bootstrap service of the listener.
You can retrieve this from the status of the `Kafka` resource.

.Example command to retrieve the address and port for client connection
[source,shell]
kubectl get kafka <kafka_cluster_name> -o=jsonpath='{.status.listeners[?(@.name=="<listener_name>")].bootstrapServers}{"\n"}'

IMPORTANT: When configuring listeners for client access to brokers, you can use port 9092 or higher (9093, 9094, and so on), but with a few exceptions.
The listeners cannot be configured to use the ports reserved for interbroker communication (9090 and 9091), Prometheus metrics (9404), and JMX (Java Management Extensions) monitoring (9999).

= Specifying listener types

Set the type to `internal` for internal listeners. 
For external listeners, choose from `route`, `loadbalancer`, `nodeport`, or `ingress`. 
You can also configure a `cluster-ip` listener, which is an internal type used for building custom access mechanisms.

internal:: You can configure internal listeners with or without encryption using the `tls` property.
+
.Example `internal` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   #...
   - name: plain
     port: 9092
     type: internal
     tls: false
   - name: tls
     port: 9093
     type: internal
     tls: true
     authentication:
       type: tls
 #...
----
route:: Configures an external listener to expose Kafka using OpenShift `Routes` and the HAProxy router.
+
A dedicated `Route` is created for every Kafka broker pod.
An additional `Route` is created to serve as a Kafka bootstrap address.
Kafka clients can use these `Routes` to connect to Kafka on port 443.
The client connects on port 443, the default router port, but traffic is then routed to the port you configure,
which is `9094` in this example.
+
.Example `route` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   #...
   - name: external1
     port: 9094
     type: route
     tls: true
 #...
----
ingress:: Configures an external listener to expose Kafka using Kubernetes `Ingress` and the {NginxIngressController}.
+
IMPORTANT: The `ingress` listener type is deprecated because the {NginxIngressController} has been archived since March 2026.
Although the related code remains in the Strimzi codebase, it is no longer maintained, and no further enhancements or development are planned.
+
A dedicated `Ingress` resource is created for every Kafka broker pod.
An additional `Ingress` resource is created to serve as a Kafka bootstrap address.
Kafka clients can use these `Ingress` resources to connect to Kafka on port 443.
The client connects on port 443, the default controller port, but traffic is then routed to the port you configure,
which is `9095` in the following example.
+
You must specify the hostname used by the bootstrap service using xref:type-GenericKafkaListenerConfigurationBootstrap-reference[`GenericKafkaListenerConfigurationBootstrap`] property.
And you must also specify the hostnames used by the per-broker services
using xref:type-GenericKafkaListenerConfigurationBroker-reference[`GenericKafkaListenerConfigurationBroker`]
or xref:type-GenericKafkaListenerConfiguration-reference[`hostTemplate`] properties.
With the `hostTemplate` property, you don't need to specify the configuration for every broker.
+
.Example `ingress` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   #...
   - name: external2
     port: 9095
     type: ingress
     tls: true
     authentication:
       type: tls
     configuration:
       hostTemplate: broker-{nodeId}.myingress.com
       bootstrap:
         host: bootstrap.myingress.com
  #...
----
+
NOTE: External listeners using `Ingress` are currently only tested with the {NginxIngressController}.

loadbalancer:: Configures an external listener to expose Kafka using a `Loadbalancer` type `Service`.
+
A new loadbalancer service is created for every Kafka broker pod.
An additional loadbalancer is created to serve as a Kafka _bootstrap_ address.
Loadbalancers listen to the specified port number, which is port `9094` in the following example.
+
You can use the `loadBalancerSourceRanges` property to configure xref:property-listener-config-source-ranges-reference[source ranges] to restrict access to the specified IP addresses.
+
.Example `loadbalancer` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   - name: external3
     port: 9094
     type: loadbalancer
     tls: true
     configuration:
       loadBalancerSourceRanges:
         - 10.0.0.0/8
         - 88.208.76.87/32
 #...
----

nodeport:: Configures an external listener to expose Kafka using a `NodePort` type `Service`.
+
Kafka clients connect directly to the nodes of Kubernetes.
An additional `NodePort` type of service is created to serve as a Kafka bootstrap address.
+
When configuring the advertised addresses for the Kafka broker pods, Strimzi uses the address of the node on which the given pod is running.
+
You can use `preferredNodePortAddressType` property to configure the xref:property-listener-config-preferredNodePortAddressType-{context}[first address type checked as the node address].
+
.Example `nodeport` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   #...
   - name: external4
     port: 9095
     type: nodeport
     tls: false
     configuration:
       preferredNodePortAddressType: InternalDNS
 #...
----
NOTE: TLS hostname verification is not currently supported when exposing Kafka clusters using node ports.

cluster-ip:: Configures an internal listener to expose Kafka using a per-broker `ClusterIP` type `Service`.
+
The listener does not use a headless service and its DNS names to route traffic to Kafka brokers.
You can use this type of listener to expose a Kafka cluster when using the headless service is unsuitable. 
You might use it with a custom access mechanism, such as one that uses a specific Ingress controller or the Kubernetes Gateway API. 
+
A new `ClusterIP` service is created for each Kafka broker pod.
The service is assigned a `ClusterIP` address to serve as a Kafka _bootstrap_ address with a per-broker port number.
For example, you can configure the listener to expose a Kafka cluster over an Nginx Ingress Controller with TCP port configuration. 
+
.Example `cluster-ip` listener configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   - name: clusterip
     type: cluster-ip
     tls: false
     port: 9096
 #...

----

[id='configuration-listener-network-policy-{context}']
= Configuring network policies to restrict listener access

Use `networkPolicyPeers` to configure network policies that restrict access to a listener at the network level.
The following example shows a `networkPolicyPeers` configuration for a `plain` and a `tls` listener.

In the following example:

* Only application pods matching the labels `app: kafka-sasl-consumer` and `app: kafka-sasl-producer` can connect to the `plain` listener.
The application pods must be running in the same namespace as the Kafka broker.
* Only application pods running in namespaces matching the labels `project: myproject` and `project: myproject2` can connect to the `tls` listener.

The syntax of the `networkPolicyPeers` property is the same as the `from` property in `NetworkPolicy` resources.

.Example network policy configuration
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: plain
 port: 9092
 type: internal
 tls: true
 authentication:
   type: scram-sha-512
 networkPolicyPeers:
   - podSelector:
       matchLabels:
         app: kafka-sasl-consumer
   - podSelector:
       matchLabels:
         app: kafka-sasl-producer
  - name: tls
 port: 9093
 type: internal
 tls: true
 authentication:
   type: tls
 networkPolicyPeers:
   - namespaceSelector:
       matchLabels:
         project: myproject
   - namespaceSelector:
       matchLabels:
         project: myproject2
# ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Listener.GenericKafkaListenerConfiguration (`documentation/api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfiguration.adoc`)

:_mod-docs-content-type: CONCEPT

Configures Kafka listeners.

[id='property-listener-config-brokerCertChainAndKey-{context}']
= Providing your own listener certificates

The `brokerCertChainAndKey` property is for listeners that have TLS encryption enabled only. 
Use this property to provide your own Kafka listener certificates.

.Example `loadbalancer` listener configuration to provide certificates
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external3
 port: 9094
 type: loadbalancer
 tls: true
 configuration:
   brokerCertChainAndKey:
     secretName: my-secret
     certificate: my-listener-certificate.crt
     key: my-listener-key.key
# ...
----

When the certificate or key in the `brokerCertChainAndKey` secret is updated, the operator automatically detects it in the next reconciliation and triggers a rolling update of the Kafka brokers to reload the certificate.

NOTE: The private key referenced in `brokerCertChainAndKey` must be in an unencrypted PKCS #8 format. If you obtain the certificate is obtained using the {CertManagerProject}, you can set {CertManagerPrivateKeyEncoding} to use PKCS#8.

[id='property-listener-config-traffic-policy-{context}']
= Avoiding hops to other nodes

The `externalTrafficPolicy` property is used with `loadbalancer` and `nodeport` listeners.
When exposing Kafka outside of Kubernetes, you can choose `Local` or `Cluster`.
`Local` avoids hops to other nodes and preserves the client IP, whereas `Cluster` does neither.
The default is `Cluster`.

.Example `loadbalancer` listener configuration avoiding hops
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external3
 port: 9094
 type: loadbalancer
 tls: true
 configuration:
   externalTrafficPolicy: Local   
# ...
----

[id='property-listener-config-source-ranges-{context}']
= Providing CIDR source ranges for a loadbalancer

The `loadBalancerSourceRanges` property is for `loadbalancer` listeners only. 
When exposing Kafka outside of Kubernetes, use CIDR (Classless Inter-Domain Routing) source ranges in addition to labels and annotations to customize how a service is created.

.Example `loadbalancer` listener configuration to provide source ranges
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external3
 port: 9094
 type: loadbalancer
 tls: true
 configuration:
   loadBalancerSourceRanges:
     - 10.0.0.0/8
     - 88.208.76.87/32    
# ...
----

[id='property-listener-config-preferredNodePortAddressType-{context}']
= Specifying a preferred node port address type

The `preferredNodePortAddressType` property is for `nodeport` listeners only.
Use this property in your listener configuration to specify the first address type checked as the node address. 
This property is useful, for example, if your deployment does not have DNS support or you only want to expose a broker internally through an internal DNS or IP address. 

If an address of this type is found, it is used. If the preferred address type is not found, Strimzi proceeds through the types in the standard order of priority:

* ExternalDNS
* ExternalIP
* Hostname
* InternalDNS
* InternalIP

.Example `nodeport` listener using a preferred node port address type
[source,yaml,subs=attributes+]
----
listeners:
  #...
  - name: external4
 port: 9094
 type: nodeport
 tls: false
 configuration:
   preferredNodePortAddressType: InternalDNS
# ...
----

[id='property-listener-config-dns-{context}']
= Using fully-qualified DNS names

The `useServiceDnsDomain` property is for `internal` and `cluster-ip` listeners. 
It defines whether the fully-qualified DNS names that include the cluster service suffix (usually `.cluster.local`) are used. 

* Set to `false` (default) to generate advertised addresses without the service suffix; for example, `my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc`. 
* Set to `true` to generate advertised addresses with the service suffix; for example, `my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc.cluster.local`.

.Example `internal` listener using the service DNS domain
[source,yaml,subs=attributes+]
----
listeners:
  #...
  - name: plain
 port: 9092
 type: internal
 tls: false
 configuration:
   useServiceDnsDomain: true
# ...
----

[id='property-listener-config-host-{context}']
= Specifying the hostname

To specify the hostname used for the bootstrap resource or brokers, use the `host` property.
The `host` property is for `route` and `ingress` listeners only.

A `host` property value is mandatory for ingress listener configuration, as the Ingress controller does not assign any hostnames automatically. 
Make sure that the hostname resolves to the Ingress endpoints. 
Strimzi will not perform any validation to ensure that the requested hosts are available and properly routed to the Ingress endpoints.

.Example `ingress` listener with host configuration
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external2
 port: 9094
 type: ingress
 tls: true
 configuration:
   bootstrap:
     host: bootstrap.myingress.com
   brokers:
   - broker: 0
     host: broker-0.myingress.com
   - broker: 1
     host: broker-1.myingress.com
   - broker: 2
     host: broker-2.myingress.com
# ...
----

By default, route listener hosts are automatically assigned by OpenShift. 
However, you can override the assigned route hosts by specifying hosts.

Strimzi does not perform any validation to ensure that the requested hosts are available. 
You must ensure that they are free and can be used.

.Example `route` listener with host configuration
[source,yaml,subs="attributes+"]
----
# ...
listeners:
  #...
  - name: external1
 port: 9094
 type: route
 tls: true
 configuration:
   bootstrap:
     host: bootstrap.myrouter.com
   brokers:
   - broker: 0
     host: broker-0.myrouter.com
   - broker: 1
     host: broker-1.myrouter.com
   - broker: 2
     host: broker-2.myrouter.com
# ...
----

Instead of specifying the `host` property for every broker, you can also use a `hostTemplate` to generate them automatically.
The `hostTemplate` supports the following variables:

* The `{nodeId}` variable is replaced with the ID of the Kafka node to which the template is applied.
* The `{nodePodName}` variable is replaced with the Kubernetes pod name for the Kafka node where the template is applied.

The `hostTemplate` property applies only to per-broker values.
The bootstrap `host` property must always be specified.

.Example `ingress` listener with `hostTemplate` configuration
[source,yaml,subs="+attributes"]
----
#...
spec:
  kafka:
 #...
 listeners:
   #...
   - name: external2
     port: 9095
     type: ingress
     tls: true
     authentication:
       type: tls
     configuration:
       hostTemplate: broker-{nodeId}.myingress.com
       bootstrap:
         host: bootstrap.myingress.com
  #...
----

[id='property-listener-config-nodeport-{context}']
= Overriding assigned node ports

By default, the port numbers used for the bootstrap and broker services are automatically assigned by Kubernetes.
You can override the assigned node ports for `nodeport` listeners by specifying the desired port numbers.

Strimzi does not perform any validation on the requested ports.
You must ensure that they are free and available for use.

.Example `nodeport` listener configuration with overrides for node ports
[source,yaml,subs="attributes+"]
----
# ...
listeners:
  #...
  - name: external4
 port: 9094
 type: nodeport
 tls: true
 configuration:
   bootstrap:
     nodePort: 32100
   brokers:
   - broker: 0
     nodePort: 32000
   - broker: 1
     nodePort: 32001
   - broker: 2
     nodePort: 32002
# ...
----

[id='property-listener-config-lb-ip-{context}']
= Requesting a specific loadbalancer IP address 

Use the `loadBalancerIP` property to request a specific IP address when creating a loadbalancer.
This property is useful when you need to use a loadbalancer with a specific IP address.
The `loadBalancerIP` property is ignored if the cloud provider does not support this feature.

.Example `loadbalancer` listener with specific IP addresses
[source,yaml,subs="attributes+"]
----
# ...
listeners:
  #...
  - name: external3
 port: 9094
 type: loadbalancer
 tls: true
 configuration:
   bootstrap:
     loadBalancerIP: 172.29.3.10
   brokers:
   - broker: 0
     loadBalancerIP: 172.29.3.1
   - broker: 1
     loadBalancerIP: 172.29.3.2
   - broker: 2
     loadBalancerIP: 172.29.3.3
# ...
----

[id='property-listener-config-annotations-{context}']
= Adding listener annotations to Kubernetes resources 

Use the `annotations` property to add annotations to Kubernetes resources related to the listeners.
These annotations can be used, for example, to instrument DNS tooling such as {KubernetesExternalDNS}, which automatically assigns DNS names to the loadbalancer services.

.Example `loadbalancer` listener using `annotations`
[source,yaml,subs="attributes+"]
----
# ...
listeners:
  #...
  - name: external3
 port: 9094
 type: loadbalancer
 tls: true
 configuration:
   bootstrap:
     annotations:
       external-dns.alpha.kubernetes.io/hostname: kafka-bootstrap.mydomain.com.
       external-dns.alpha.kubernetes.io/ttl: "60"
   brokers:
   - broker: 0
     annotations:
       external-dns.alpha.kubernetes.io/hostname: kafka-broker-0.mydomain.com.
       external-dns.alpha.kubernetes.io/ttl: "60"
   - broker: 1
     annotations:
       external-dns.alpha.kubernetes.io/hostname: kafka-broker-1.mydomain.com.
       external-dns.alpha.kubernetes.io/ttl: "60"
   - broker: 2
     annotations:
       external-dns.alpha.kubernetes.io/hostname: kafka-broker-2.mydomain.com.
       external-dns.alpha.kubernetes.io/ttl: "60"
# ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Listener.GenericKafkaListenerConfigurationBootstrap (`documentation/api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfigurationBootstrap.adoc`)

:_mod-docs-content-type: CONCEPT

Configures bootstrap service settings for listeners.

Example configuration for the `host`, `nodePort`, `loadBalancerIP`, and `annotations` properties is shown in the xref:type-GenericKafkaListenerConfiguration-reference[`GenericKafkaListenerConfiguration` schema] section.

[id='property-listener-config-altnames-{context}']
= Specifying alternative bootstrap addresses

To specify alternative names for the bootstrap address, use the `alternativeNames` property.
This property is applicable to all types of listeners.
The names are added to the broker certificates and can be used for TLS hostname verification.

.Example `route` listener configuration with additional bootstrap addresses
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external1
 port: 9094
 type: route
 tls: true
 configuration:
   bootstrap:
     alternativeNames:
       - example.hostname1
       - example.hostname2 
# ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Listener.GenericKafkaListenerConfigurationBroker (`documentation/api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfigurationBroker.adoc`)

:_mod-docs-content-type: CONCEPT

Configures broker settings for listeners.

Example configuration for the `host`, `nodePort`, `loadBalancerIP`, and `annotations` properties is shown in the xref:type-GenericKafkaListenerConfiguration-reference[`GenericKafkaListenerConfiguration` schema] section.

[id='property-listener-config-broker-{context}']
= Overriding advertised addresses for brokers

By default, Strimzi tries to automatically determine the hostnames and ports that your Kafka cluster advertises to its clients.
This is not sufficient in all situations, because the infrastructure on which Strimzi is running might not provide the right hostname or port through which Kafka can be accessed.

You can specify a broker ID and customize the advertised hostname and port in the `configuration` property of the listener.
Strimzi will then automatically configure the advertised address in the Kafka brokers and add it to the broker certificates so it can be used for TLS hostname verification.
Overriding the advertised host and ports is available for all types of listeners.

.Example of an external `route` listener configured with overrides for advertised addresses
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external1
 port: 9094
 type: route
 tls: true
 configuration:
   brokers:
   - broker: 0
     advertisedHost: example.hostname.0
     advertisedPort: 12340
   - broker: 1
     advertisedHost: example.hostname.1
     advertisedPort: 12341
   - broker: 2
     advertisedHost: example.hostname.2
     advertisedPort: 12342
# ...
----

Instead of specifying the `advertisedHost` and `advertisedPort` fields for every broker, you can also use an `advertisedHostTemplate` and `advertisedPortTemplate` to generate them automatically.

The `advertisedHostTemplate` supports the following variables which are replaced with the actual values when the configuration is applied to the Kafka cluster:

* The `{nodeId}` variable is replaced with the ID of the Kafka node to which the template is applied.
* The `{nodePodName}` variable is replaced with the Kubernetes pod name for the Kafka node where the template is applied.

The `advertisedPortTemplate` works as a simple mathematical formula where you can use the `{nodeId}` variable to calculate the port number for each broker.
The supported operations are addition (`+`), subtraction (`-`), multiplication (`*`), and brackets (`(`, `)`).
For example, if you set `advertisedPortTemplate` to `12340 + {nodeId}`, the broker with the node ID `0` will have the advertised port `12340`, the broker with node ID `2` will have advertised port `12342`, and so on.
You can also set `advertisedPortTemplate` to a simple number without using the `nodeId` variable, in which case all brokers will have the same advertised port.

.Example `route` listener with `advertisedHostTemplate` configuration
[source,yaml,subs="attributes+"]
----
listeners:
  #...
  - name: external1
 port: 9094
 type: route
 tls: true
 configuration:
   advertisedHostTemplate: example.hostname.{nodeId}
   advertisedPortTemplate: 12340 + {nodeId}
# ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Listener.KafkaListenerAuthenticationCustom (`documentation/api/io.strimzi.api.kafka.model.kafka.listener.KafkaListenerAuthenticationCustom.adoc`)

:_mod-docs-content-type: CONCEPT

Configures custom authentication for listeners.

To configure custom authentication, set the `type` property to `custom`.
Custom authentication allows for any type of Kafka-supported authentication to be used.

.Example custom OAuth authentication configuration
[source,yaml,subs="attributes+"]
----
spec:
  kafka:
 config:
   principal.builder.class: SimplePrincipal.class
 listeners:
   - name: oauth-bespoke
     port: 9093
     type: internal
     tls: true
     authentication:
       type: custom
       sasl: true
       listenerConfig:
         oauthbearer.sasl.client.callback.handler.class: client.class
         oauthbearer.sasl.server.callback.handler.class: server.class
         oauthbearer.sasl.login.callback.handler.class: login.class
         oauthbearer.connections.max.reauth.ms: 999999999
         sasl.enabled.mechanisms: oauthbearer
         oauthbearer.sasl.jaas.config: |
           org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required ;
 template:
   pod:
     volumes:
       - name: example-secret
         secret:
           secretName: example
   kafkaContainer:
     volumeMounts:
       - name: example-secret
         mountPath: /mnt/secret-volume
----

A protocol map is generated that uses the `sasl` and `tls` values to determine which protocol to map to the listener.

* SASL = True, TLS = True -> SASL_SSL
* SASL = False, TLS = True -> SSL
* SASL = True, TLS = False -> SASL_PLAINTEXT
* SASL = False, TLS = False -> PLAINTEXT

Secrets are mounted to the `/mnt` directory in the Kafka broker nodes' containers.
For example, the mounted secret (`example`) in the example configuration would be located at `/mnt/secret-volume`.

= Configuring customized TLS Client Authentication

You can also use the `custom` authentication to configure customized TLS client authentication.
This allows configuration options that are not permissible with `type: tls` authentication.
For example, it's possible to configure a custom truststore with multiple trusted CAs or options such as `ssl.principal.mapping.rules`.

.Example custom TLS Client Authentication configuration
[source,yaml,subs="attributes+"]
----
spec:
  kafka:
 listeners:
   - name: tls
     port: 9093
     tls: true
     type: internal
     authentication:
       type: custom
       sasl: false
       listenerConfig:
         ssl.client.auth: required
         ssl.principal.mapping.rules: RULE:^CN=(.*?),(.*)$/[email protected]/
         ssl.truststore.location: /mnt/my-truststore/ca.crt
         ssl.truststore.type: PEM
 template:
   pod:
     volumes:
       - name: my-truststore
         secret:
           secretName: custom-truststore
   kafkaContainer:
     volumeMounts:
       - name: my-truststore
         mountPath: /mnt/my-truststore
----

= Configuring Service Account-based authentication

You can also use `custom` authentication to authenticate clients with Kubernetes Service Account tokens.
Kubernetes issues the tokens and publishes the keys needed to validate them, so you don't have to run and manage your own OAuth server.
This makes Service Account tokens a convenient option for internal listeners used by clients that run in the same Kubernetes cluster as the Kafka cluster.

The listener uses the `OAUTHBEARER` SASL mechanism and validates the tokens as JSON Web Tokens (JWTs) against the JSON Web Key Set (JWKS) endpoint published by the Kubernetes API server.
Strimzi mounts the Service Account token of the Kafka node together with the Kubernetes CA certificate into the `/var/run/secrets/kubernetes.io/serviceaccount` directory of the Kafka containers.
The listener configuration uses them to authenticate against the JWKS endpoint and to trust the TLS certificate of the Kubernetes API server.

.Example Service Account-based authentication configuration
[source,yaml,subs="attributes+"]
----
spec:
  kafka:
 config:
   # Required by the Strimzi OAuth library
   principal.builder.class: io.strimzi.kafka.oauth.server.OAuthKafkaPrincipalBuilder
 listeners:
   - name: sa
     port: 9093
     type: internal
     tls: true
     authentication:
       type: custom
       sasl: true
       listenerConfig:
         sasl.enabled.mechanisms: OAUTHBEARER
         oauthbearer.sasl.server.callback.handler.class: io.strimzi.kafka.oauth.server.JaasServerOauthValidatorCallbackHandler
         oauthbearer.sasl.jaas.config: |
           org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required
             unsecuredLoginStringClaim_sub="unused"
             oauth.check.access.token.type="false"
             oauth.custom.claim.check="@.aud anyof ['my-internal-listener']"
             oauth.valid.issuer.uri="https://kubernetes.default.svc.cluster.local"
             oauth.jwks.endpoint.uri="https://kubernetes.default.svc.cluster.local/openid/v1/jwks"
             oauth.jwks.refresh.seconds="300"
             oauth.username.claim="sub"
             oauth.ssl.truststore.location="/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"
             oauth.ssl.truststore.type="PEM"
             oauth.server.bearer.token.location="/var/run/secrets/kubernetes.io/serviceaccount/token"
             oauth.include.accept.header="false";
----

In this configuration:

* `principal.builder.class` maps the validated tokens to Kafka principals.
For more information on the requirements that apply to principal builders, see the description of setting a custom principal builder that follows.
* `unsecuredLoginStringClaim_sub` satisfies the parameter validation of the `OAuthBearerLoginModule` and isn't used for authentication.
* `oauth.check.access.token.type` is disabled because Service Account tokens don't contain the `typ` claim expected by the OAuth standard.
* `oauth.custom.claim.check` restricts the listener to tokens issued for a specific audience.
* `oauth.valid.issuer.uri` is the token issuer of your Kubernetes cluster and is checked against the `iss` claim of the token.
* `oauth.jwks.endpoint.uri` points to the JWKS endpoint of the Kubernetes API server, which publishes the keys used to sign the Service Account tokens.
Tokens are validated locally by the Kafka nodes using these keys.
* `oauth.username.claim` uses the `sub` claim of the token as the name of the Kafka principal.
* `oauth.server.bearer.token.location` and `oauth.ssl.truststore.location` point to the Service Account token and the Kubernetes CA certificate mounted by Strimzi into the Kafka containers.
The token is used to authenticate against the JWKS endpoint, which is not available to unauthenticated users by default.
* `oauth.include.accept.header` is disabled because the Kubernetes API server rejects requests that set the `Accept` header.

NOTE: The issuer URI and the address of the JWKS endpoint depend on your Kubernetes cluster.
Many Kubernetes clusters use `https://kubernetes.default.svc.cluster.local`, but managed Kubernetes services often use a different, externally hosted issuer.
To find the values used by your cluster, run `kubectl get --raw /.well-known/openid-configuration` and check the `issuer` and `jwks_uri` fields.

== Kafka principals and ACLs

Clients are identified by the `sub` claim of the token, which for Service Account tokens has the format `system:serviceaccount:<namespace>:<service_account_name>`.
Strimzi operands use a Service Account named after the component: `<connect_cluster_name>-connect` for Kafka Connect, `<mirror_maker_2_cluster_name>-mirrormaker2` for MirrorMaker 2, and `-bridge` for the HTTP Bridge.
For example, a Kafka Connect cluster named `my-connect` deployed in the `myproject` namespace authenticates as `User:system:serviceaccount:myproject:my-connect-connect`.
Use these names when configuring ACL rules.

== Restricting the token audience

Without an audience check, any Service Account token from the Kubernetes cluster can be used to authenticate to the Kafka cluster, including the tokens that Pods use to communicate with the Kubernetes API.
The `oauth.custom.claim.check` option in the example accepts only tokens that have `my-internal-listener` in their `aud` claim.
Tokens issued for a custom audience are in turn rejected by the Kubernetes API server, which limits how they can be used if they leak.

Clients have to request a token with a matching audience.
Strimzi operands can do this using a projected Service Account token volume, as described in the xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom` schema reference].

= Setting a custom principal builder

You can set a custom principal builder in the Kafka cluster configuration.
However, the principal builder is subject to the following requirements:

* The specified principal builder class must exist on the image.
_Before_ building your own, check if one already exists.
You'll need to rebuild the Strimzi images with the required classes.
* No other listener is using `oauth` type authentication.
This is because an OAuth listener appends its own principle builder to the Kafka configuration.
* The specified principal builder is compatible with Strimzi.

Custom principal builders must support peer certificates for authentication, as Strimzi uses these to manage the Kafka cluster.

ifdef::Section[]
A custom OAuth principal builder might be identical or very similar to the Strimzi https://github.com/strimzi/strimzi-kafka-oauth/blob/main/oauth-server/src/main/java/io/strimzi/kafka/oauth/server/OAuthKafkaPrincipalBuilder.java[OAuth principal builder].
endif::Section[]

NOTE: link:https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/authenticator/DefaultKafkaPrincipalBuilder.java#L73-L79[Kafka's default principal builder class] supports the building of principals based on the names of peer certificates.
The custom principal builder should provide a principal of type `user` using the name of the SSL peer certificate.

The following example shows a custom principal builder that satisfies the OAuth requirements of Strimzi.

.Example principal builder for custom OAuth configuration
[source,java,subs="attributes+"]
----
public final class CustomKafkaPrincipalBuilder implements KafkaPrincipalBuilder {

 public KafkaPrincipalBuilder() {}

 @Override
 public KafkaPrincipal build(AuthenticationContext context) {
     if (context instanceof SslAuthenticationContext) {
         SSLSession sslSession = ((SslAuthenticationContext) context).session();
         try {
             return new KafkaPrincipal(
                 KafkaPrincipal.USER_TYPE, sslSession.getPeerPrincipal().getName());
         } catch (SSLPeerUnverifiedException e) {
             throw new IllegalArgumentException("Cannot use an unverified peer for authentication", e);
         }
     }

     // Create your own KafkaPrincipal here
     ...
 }
}
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Kafka.Tieredstorage.TieredStorageCustom (`documentation/api/io.strimzi.api.kafka.model.kafka.tieredstorage.TieredStorageCustom.adoc`)

:_mod-docs-content-type: CONCEPT

Enables custom tiered storage for Kafka.

If you want to use custom tiered storage, you must first add a tiered storage for Kafka plugin to the Strimzi image by building a custom container image.

Custom tiered storage configuration enables the use of a custom `RemoteStorageManager` configuration.
`RemoteStorageManager` is a Kafka interface for managing the interaction between Kafka and remote tiered storage.

If custom tiered storage is enabled, Strimzi uses the https://github.com/apache/kafka/blob/trunk/storage/src/main/java/org/apache/kafka/server/log/remote/metadata/storage/TopicBasedRemoteLogMetadataManager.java[`TopicBasedRemoteLogMetadataManager`^] for Remote Log Metadata Management (RLMM).

NOTE: Tiered storage is a production-ready feature in Kafka since version 3.9.0, and it is also supported in Strimzi.
Before introducing tiered storage to your environment, review the {ApacheKafkaTieredStorageLimitations} of this feature.

.Example custom tiered storage configuration
[source,yaml,subs="attributes+"]
----
kafka:
  tieredStorage:
 type: custom
 remoteStorageManager:
   className: com.example.kafka.tiered.storage.s3.S3RemoteStorageManager
   classPath: /opt/kafka/plugins/tiered-storage-s3/*
   config:
     # A map with String keys and String values.
     # Key properties are automatically prefixed with `rsm.config.` 
     # and appended to Kafka broker config.
     storage.bucket.name: my-bucket
  config:
 ...
 # Additional RLMM configuration can be added through the Kafka config 
 # under `spec.kafka.config` using the `rlmm.config.` prefix.
 rlmm.config.remote.log.metadata.topic.replication.factor: 1
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Mirrormaker2.KafkaMirrorMaker2ClusterSpec (`documentation/api/io.strimzi.api.kafka.model.mirrormaker2.KafkaMirrorMaker2ClusterSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures Kafka clusters for mirroring.

Use the `config` properties to configure Kafka options, restricted to those properties not managed directly by Strimzi.

For client connection using a specific _cipher suite_ for a TLS version, you can xref:con-common-configuration-ssl-reference[configure allowed `ssl` properties].
You can also xref:con-common-configuration-ssl-reference[configure the `ssl.endpoint.identification.algorithm` property] to enable or disable hostname verification.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Mirrormaker2.KafkaMirrorMaker2TargetClusterSpec (`documentation/api/io.strimzi.api.kafka.model.mirrormaker2.KafkaMirrorMaker2TargetClusterSpec.adoc`)

:_mod-docs-content-type: CONCEPT

Configures the target Apache Kafka cluster for a MirrorMaker 2 deployment.
The target Kafka cluster is used by the underlying Kafka Connect framework for its internal topics.

[id='property-kafka-mirrormaker2-target-internal-topics-grop-id-{context}']
= Group ID and internal topics

The group ID and the internal topics used by the Kafka Connect cluster are configured in the `.spec.target` section of the `KafkaMirrorMaker2` resource.
These properties are required.

.Example group ID and internal topics configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaMirrorMaker2ApiVersion}
kind: KafkaMirrorMaker2
metadata:
  name: my-mirrormaker-2
spec:
  # ...
  target:
 # ...
 groupId: my-connect-group
 configStorageTopic: my-config-topic
 offsetStorageTopic: my-offset-topic
 statusStorageTopic: my-status-topic
  # ...
----

[id='property-kafka-mirrormaker2-target-additional-configuration-{context}']
= Additional configuration

Use the `config` properties to configure Kafka options, restricted to those properties not managed directly by Strimzi.

For client connection using a specific _cipher suite_ for a TLS version, you can xref:con-common-configuration-ssl-reference[configure allowed `ssl` properties].
You can also xref:con-common-configuration-ssl-reference[configure the `ssl.endpoint.identification.algorithm` property] to enable or disable hostname verification.

.Example target cluster configuration
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaMirrorMaker2ApiVersion}
kind: KafkaMirrorMaker2
metadata:
  name: my-mirrormaker-2
spec:
  # ...
  target:
 # ...
 config:
   config.storage.replication.factor: -1
   offset.storage.replication.factor: -1
   status.storage.replication.factor: -1
  # ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.Podset.StrimziPodSet (`documentation/api/io.strimzi.api.kafka.model.podset.StrimziPodSet.adoc`)

:_mod-docs-content-type: CONCEPT

IMPORTANT: `StrimziPodSet` is an internal Strimzi resource.
Information is provided for reference only.
Do not create, modify or delete `StrimziPodSet` resources as this might cause errors.

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.User.KafkaUserQuotas (`documentation/api/io.strimzi.api.kafka.model.user.KafkaUserQuotas.adoc`)

:_mod-docs-content-type: CONCEPT

Configure clients to use quotas so that a user does not overload Kafka brokers.

.Example Kafka user quota configuration
[source,yaml,subs=attributes+]
----
spec:
  quotas:
 producerByteRate: 1048576
 consumerByteRate: 2097152
 requestPercentage: 55
 controllerMutationRate: 10
----

For more information, see the link:{ApacheKafkaDocsBase}design/design/[Apache Kafka design documentation^].

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.User.KafkaUserTemplate (`documentation/api/io.strimzi.api.kafka.model.user.KafkaUserTemplate.adoc`)

:_mod-docs-content-type: CONCEPT

Specify additional labels and annotations for the secret created by the User Operator.

.An example showing the `KafkaUserTemplate`
[source,yaml,subs=attributes+]
----
apiVersion: {KafkaUserApiVersion}
kind: KafkaUser
metadata:
  name: my-user
  labels:
 strimzi.io/cluster: my-cluster
spec:
  authentication:
 type: tls
  template:
 secret:
   metadata:
     labels:
       label1: value1
     annotations:
       anno1: value1
  # ...
----

---

### Documentation Api Io.Strimzi.Api.Kafka.Model.User.Acl.AclRule (`documentation/api/io.strimzi.api.kafka.model.user.acl.AclRule.adoc`)

:_mod-docs-content-type: CONCEPT

Configures access control rules for a `KafkaUser` when brokers are using `simple` authorization.

.Example `KafkaUser` configuration with simple authorization
[source,yaml,subs="attributes+"]
----
apiVersion: {KafkaUserApiVersion}
kind: KafkaUser
metadata:
  name: my-user
  labels:
 strimzi.io/cluster: my-cluster
spec:
  # ...
  authorization:
 type: simple
 acls:
   - resource:
       type: topic
       name: "*"
       patternType: literal
     operations:
       - Read
       - Describe
   - resource:
       type: group
       name: my-group
       patternType: prefix
     operations:
       - Read
----

Use the `resource` property to specify the resource that the rule applies to.

Simple authorization supports four resource types, which are specified in the `type` property:

* Topics (`topic`)
* Consumer Groups (`group`)
* Clusters (`cluster`)
* Transactional IDs (`transactionalId`)

For Topic, Group, and Transactional ID resources you can specify the name of the resource the rule applies to in the `name` property.

Cluster type resources have no name.

A name is specified as a `literal` or a `prefix` using the `patternType` property.

* Literal names are taken exactly as they are specified in the `name` field.
* Prefix names use the `name` value as a prefix and then apply the rule to all resources with names starting with that value.

When `patternType` is set as `literal`, you can set the name to `*` to indicate that the rule applies to all resources.

For more details about `simple` authorization, ACLs, and supported combinations of resources and operations, see link:{ApacheKafkaDocsBase}security/authorization-and-acls/[Authorization and ACLs^].

---

### Documentation Configuring Configuring (`documentation/configuring/configuring.adoc`)

include::shared/version-dependent-attrs.adoc[]
include::shared/attributes.adoc[]

:context: reference

[id="configuring-book_{context}"]
= Strimzi Custom Resource API Reference

//introduces the schema reference
include::modules/configuring/con-schema-overview.adoc[leveloffset=+1]
//properties common to more than one custom resource
include::modules/con-common-configuration-properties.adoc[leveloffset=+1]
//content built from @Description annotations in the Java files
include::modules/appendix_crds.adoc[leveloffset=+1]

---

### Documentation Contributing Contributing (`documentation/contributing/contributing.adoc`)

include::shared/attributes.adoc[]

= Strimzi documentation contributor guide

include::introduction.adoc[leveloffset=+1]

include::contributor-guide.adoc[leveloffset=+1]

include::styleguide.adoc[leveloffset=+1]

include::make-tooling.adoc[leveloffset=+1]

[appendix]
include::formatting-guide.adoc[leveloffset=+1]

[appendix]
include::git-setup-guide.adoc[leveloffset=+1]

[appendix]
include::git-tips.adoc[leveloffset=+1]

// Revision information
include::shared/revision-info.adoc[]

---

### Documentation Contributing Contributor Guide (`documentation/contributing/contributor-guide.adoc`)

[[contributing-to-docs]]
= Contributing to the documentation

This section shows you how to contribute to the Strimzi documentation and contains important guidelines for creating accessible content.

[[contribution-getting-started]]
== Getting started

Before you begin you need to:

. xref:setting-up-git[Install and set up Git]

[[contribution-accessibility]]
== Accessibility guidelines

Strimzi aims to make its content accessible.
When contributing to the documentation, ensure that your content adheres to the following guidelines:

* Images:
** Include a caption
** Provide alternative text
** Are described in the surrounding text
* Images of text are not used (such as with code fragments)
* Links provide descriptive text about the target (not _click here_)
* Tables:
** Include a caption
** Contain headings
** Provide a logical reading order
** Don't contain empty cells
* Color is not used as the only visual means to convey information (not _check the green text_)

.Example image caption and description
[source,asciidoc]
----
.Operators within the Strimzi architecture
image:operators.png[Operators within the Strimzi architecture]
----

.Example table headings
[source,asciidoc]
----
.File connectors
[cols="2*",options="header"]
|===

|File Connector
|Description

|FileStreamSourceConnector
|Transfers data to your Kafka cluster from a file (the source).
|===
----

[[contributing]]
== Adding or updating content

Once you have your local repository set up and have up-to-date copies of upstream content,
follow these steps to contribute to the documentation.

You add content to the documentation hosted on GitHub using pull requests (PRs).

Reviewers might be assigned to the PR depending on the changes.
A review from a Subject Matter Expert (SME) will check the technical aspects of the content.
The PR might not require an SME review if you're only fixing a typo or broken link.

.Procedure
. Open your terminal
. `cd` to the directory where your documentation resides
. Checkout the main branch
+
[source]
----
$ git checkout main
----
. Update your local repository and fork with the upstream content
+
[source]
----
$ git pull upstream main
$ git push origin main --force
----
. Create a new branch for your work (using the issue number is helpful)
+
[source,options="nowrap",subs="+quotes"]
----
$ git checkout -b 
----
. Make your edits in the editor of your choice
. Save your changes locally
. Build your documentation to verify that there are no build errors and that everything looks right
.. This can be done with the xref:make-tooling[Make tooling]
. If you are creating new files, add the files to the repository
+
[source,options="nowrap",subs="+quotes"]
----
$ git status
$ git add <file-name>
----

. Commit your changes
+
[source,options="nowrap",subs="+quotes"]
----
$ git commit -a -s -m "<message>"
----
+
Note that the project requires all commits to be signed off, indicating that _you_ certify the changes with the link:https://developercertificate.org/[developer certificate of origin (DCO)].
. Push your changes to your fork
+
[source]
----
$ git push origin HEAD
----
. If the update is rejected because the commit is behind, merge your changes
+
[source]
----
$ git pull upstream main
$ git push -f origin HEAD
----
. Visit your fork on GitHub
. Click *Compare & pull request*

---

### Documentation Contributing Formatting Guide (`documentation/contributing/formatting-guide.adoc`)

[[formatted-text-reference]]
= AsciiDoc format reference

Tips for which AsciiDoc markup to use when formatting text.

Monospace (```)::
[cols="50%,50%",options="header"]
|===
|Item |Example
|File names and paths |The \`/home/user/.bashrc` file ...
|Literal values | If the value is \`true` ...
|Configuration attributes | Set the \`enabled` attribute ...
|Java class names |The \`java.sql.Connection` class ...
|Java annotations |The \`@Clustered` annotation ...
|===

Italics (`_`)::
[cols="50%,50%",options="header"]
|===
|Item |Example
|Emphasis for a term _(only emphasize first time)_ |\_High availability_ refers to the ...
|===

Bold (`*`)::
[cols="50%,50%",options="header"]
|===
|Item |Example
|GUI items _(menus, buttons)_|Click the \*Add* button and ...
|===

Underline (`[.underline]#value#`)::
[cols="50%,50%",options="header"]
|===
|Item |Example
|Default item in a multi-select|\`yes\|[.underline]\#no#\|maybe`
|===

---

### Documentation Contributing Git Setup Guide (`documentation/contributing/git-setup-guide.adoc`)

[[setting-up-git]]
= Setting up git

This section explains how to set up your system to connect to the proper git repositories.

[[install-git]]
== Install git

If using Fedora, open your terminal and enter the proper installation command.

[discrete]
=== Fedora
[source]
----
$ yum install git (up to Fedora 21)
$ dnf install git (Fedora 22 and later)
----

[discrete]
=== Other operating systems

* https://git-scm.com/downloads[Download Git^]

[[configure-git]]
== Configuring git

Once you have git installed you'll want to set up your git account.

.Procedure
. Open *Terminal*
. Set your name and email
+
[source,options="nowrap",subs="+quotes"]
----
$ git config --global user.name "<your-name>"
$ git config --global user.email "<your-email>"
----
+
TIP: The email you specify should be the same one found in your https://help.github.com/articles/adding-an-email-address-to-your-github-account/[email settings^]. To keep your email address hidden, see https://help.github.com/articles/keeping-your-email-address-private[Keeping your email address private^].

. Set your git defaults
+
[source]
----
$ git config --global pull.rebase true
$ git config --global push.default simple
----

[[fork-upstream]]
== Fork the upstream (GitHub) repository

Fork the `strimzi-kafka-operator` upstream repository to create a copy under your own GitHub ID. This allows you to work on multiple features and push changes to branches in your own GitHub instance so that you do not have to worry about losing work. When you are ready, you can request the changes to be merged back into the upstream repository.

.Procedure
. Open a browser and navigate to the upstream repository located at link:https://github.com/strimzi/strimzi-kafka-operator[`https://github.com/strimzi/strimzi-kafka-operator`^]
. Click *Fork* located in the upper right under your profile icon.
. Select your user account for the location of the forked repository. This creates your own copy of the repository under your own GitHub ID.

[[add-ssh-github]]
== Add your SSH keys to GitHub

If you choose to use the SSH address for your clones, you will need to add an SSH Key to GitHub first.

.Procedure
. Open *Terminal*.
. Check to see if you have a public SSH key:
+
[source]
----
$ ls ~/.ssh/
----
. If you don't have a key, generate one:
+
[source,options="nowrap",subs="+quotes"]
----
$ ssh-keygen -t rsa -C "<your-email>"
----
. Open your key in an editor:
+
[source]
----
$ cd ~/.ssh/
$ vi id_rsa.pub
----
. Copy the contents of the file to your clipboard.
. Visit link:https://github.com/settings/keys[https://github.com/settings/keys^]
. Click *New SSH Key*.
. Give your key a name and paste the contents of your key file.
. Click *Add SSH Key*.

[[clone-forked]]
== Clone your forked upstream repository

Clone your forked repository to bring your GitHub repository files to your local machine. Your forked repository is now the `origin` repository for your local files.

NOTE: For more information about https://help.github.com/articles/fork-a-repo/[forking^] and https://help.github.com/articles/cloning-a-repository/[cloning^], consult the official https://help.github.com/[GitHub documentation^].

[discrete]
=== Using SSH

.Procedure
. Open *Terminal*.
. Navigate to the directory where you want to create the new repository folder.
. Type the following command:
+
[source,options="nowrap",subs="+quotes"]
----
$ git clone [email protected]:/strimzi-kafka-operator.git
----
. Navigate to the newly created `strimzi-kafka-operator` folder.
+
[source]
----
$ cd strimzi-kafka-operator/
----

[discrete]
=== Using HTTPS

While there are fewer steps in this option, you have to enter your GitHub credentials with every change you make.

.Procedure
. Open *Terminal*.
. Navigate to the directory where you want to create the new repository folder.
. Type the following command:
+
[source,options="nowrap",subs="+quotes"]
----
$ git clone https://github.com//strimzi-kafka-operator.git
----
. Enter your GitHub credentials to complete the clone.
. Navigate to the newly created `strimzi-kafka-operator` folder.
+
[source]
----
$ cd strimzi-kafka-operator/
----

[[add-upstream]]
== Add the upstream as a remote repository

Once you have your fork checked out and cloned locally, add the downstream repository as a remote.

[discrete]
=== Using SSH

.Procedure
. List the current remote repositories:
+
[source,options="nowrap",subs="+quotes"]
----
$ git remote -v
origin	[email protected]:/strimzi-kafka-operator.git (fetch)
origin	[email protected]:/strimzi-kafka-operator.git (push)
----
. Add the upstream as a remote repository and fetch its contents. This allows you to check out and work with the latest source code.
+
[source]
----
$ git remote add -f upstream  [email protected]:strimzi/strimzi-kafka-operator.git
----
. Enter your GitHub credentials to complete the remote add process.
. Verify the new remote was added:
+
[source,options="nowrap",subs="+quotes"]
----
$ git remote -v
origin	[email protected]:/strimzi-kafka-operator.git (fetch)
origin	[email protected]:/strimzi-kafka-operator.git (push)
upstream	[email protected]:strimzi/strimzi-kafka-operator.git (fetch)
upstream	[email protected]:strimzi/strimzi-kafka-operator.git (push)
----

[discrete]
=== Using HTTPS

.Procedure
. List the current remote repositories:
+
[source,options="nowrap",subs="+quotes"]
----
$ git remote -v
origin	https://github.com//strimzi-kafka-operator.git (fetch)
origin	https://github.com//strimzi-kafka-operator.git (push)
----
. Add the upstream as a remote repository and fetch its contents. This allows you to check out and work with the latest source code.
+
[source]
----
$ git remote add -f upstream  https://github.com/strimzi/strimzi-kafka-operator.git
----
. Enter your GitHub credentials to complete the remote add process.
. Verify the new remote was added:
+
[source,options="nowrap",subs="+quotes"]
----
$ git remote -v
origin	https://github.com//strimzi-kafka-operator.git (fetch)
origin	https://github.com//strimzi-kafka-operator.git (push)
upstream	https://github.com/strimzi/strimzi-kafka-operator.git (fetch)
upstream	https://github.com/strimzi/strimzi-kafka-operator.git (push)
----

[[url-update]]
== Updating repository URLs

If the upstream repository is moved, you can change the downstream URL by using the following command:

[source]
----
$ git remote set-url upstream https://github.com/strimzi/strimzi-kafka-operator.git
----

Use the following command any time you need to fetch the latest source code locally:

[source]
----
$ git fetch upstream
----

[[git-setup-references]]
== References

* https://git-scm.com[Official Git Site^]
* http://help.github.com[GitHub Help^]

---

### Documentation Contributing Git Tips (`documentation/contributing/git-tips.adoc`)

[[git-tips]]
= Git tips

== Delete branches

To delete all of your branches except the branch you are on:

[source]
----
$ git checkout main
$ for br in `git branch` ; do git branch -D $br ; done
----

To delete one branch:

[source,options="nowrap",subs="+quotes"]
----
$ git checkout main
$ git branch -D 
----

== Resolve conflicts

To resolve a merge conflict in an existing pull request:

[source,options="nowrap",subs="+quotes"]
----
$ git checkout 
$ git branch -u origin 
$ git pull --rebase upstream main
$ git push -f origin HEAD
----

== Reset your fork

If your fork is both ahead of and behind the origin you can reset your fork to match the origin and start with a clean slate.

[source]
----
$ git checkout main
$ git reset --hard upstream/main
$ git push origin main --force
$ git pull upstream main
$ git push origin main --force
----

== Using `ssh-agent` to save your SSH key's passphrase

If you have to enter your SSH key's passphrase whenever working with the repository from the command line, you might want to use the ssh-agent to remember the passphrase for you.

Before using the `ssh-agent` you will see a prompt to enter your passphrase after each git command.

[source]
----
[amq-repo]$ git pull --rebase upstream main
Enter passphrase for key '/home//.ssh/id_rsa':
----

To add your passphrase to the `ssh-agent`:

[source]
----
[amq-repo]$ ssh-add
Enter passphrase for /home//.ssh/id_rsa:
----

After entering your passphrase you will see confirmation that your passphrase has been saved:

[source]
----
Identity added: /home//.ssh/id_rsa (/home//.ssh/id_rsa)
----

== Access another writer’s unmerged commits

This is the process you can use if you need commits another writer has submitted in a merge request that is not yet merged.

. Check out a new topic branch from upstream/main as you normally do.
+
[source,options="nowrap",subs="+quotes"]
----
$ git fetch upstream
$ git checkout -b <new-topic-branch> upstream/main
----
. If you have not yet added that writer’s remote repository, add it now.
+
[source,options="nowrap",subs="+quotes"]
----
$ git remote add -f  [email protected]:/strimzi-kafka-operator.git
----
. Rebase to bring in the changes that are in that user’s outstanding
 `origin/<merge-request-branch>` branch.
+
[source,options="nowrap",subs="+quotes"]
----
$ git rebase /<merge-request-branch>
----
+
(you'll see the following response)
+
[source,options="nowrap",subs="+quotes"]
----
First, rewinding head to replay your work on top of it...
Fast-forwarded <new-topic-branch> to /<merge-request-branch>
----

---

### Documentation Contributing Introduction (`documentation/contributing/introduction.adoc`)

= Introduction

This guide provides information to assist contributors to the Strimzi documentation.

Strimzi documentation is written in Asciidoc.

.Inclusive language

Strimzi is committed to using inclusive and respectful language in its code, web pages, and documentation.
Contributions to the documentation, as with code submissions, must not contain problematic terms or phrases.

== Documentation tools

The following tools are needed to build the documentation:

https://asciidoctor.org/[Asciidoctor^]:: Documentation generation tool
https://www.gnu.org/software/make/[`make`^]:: Make build system to build complete documentation
https://github.com/mikefarah/yq[`yq`^]:: YAML build tool to build documentation using _make_ targets

Additionally, for generating API reference content you also need the following:

https://adoptopenjdk.net/[`java`^]:: Java for building code and generating the API reference
https://maven.apache.org/[`mvn`^]:: Maven for running the Java build

For most documentation updates, Asciidoctor offers the simplest way to check the build.

== Project layout

Strimzi uses public GitHub repositories to host files.
The following repositories contain source documentation files.

https://github.com/strimzi/strimzi-kafka-operator[`strimzi-kafka-operator`^] (GitHub):: Strimzi operators code and related documentation.
https://github.com/strimzi/strimzi-kafka-bridge[`strimzi-kafka-bridge`^] (GitHub):: HTTP Bridge code and related documentation.
https://github.com/strimzi/strimzi.github.io[`strimzi.github.io`^] (GitHub):: Strimzi web site code and quick start documentation.

== Strimzi operators documentation

The main Strimzi documentation is maintained in the https://github.com/strimzi/strimzi-kafka-operator/tree/main/documentation[`/documentation` folder^] of the Strimzi Operators repository.
The _documentation_ folder is split into _category_ folders to manage the content.

The folders contain files related to Strimzi guides and the files that provide the content for one or more of these guides – _assemblies_ and _modules_.
Assemblies, which usually encapsulate a feature or process, bring the related content contained in modules together.
An assembly is like a sub-section or chapter in a book.
A module contain a procedure, concepts or reference content.

=== Strimzi Overview guide

The intention of the _Strimzi Overview guide_ is for developing an understanding of Strimzi and Apache Kafka.
The guide does not contain any instructions.
It provides an overview of the concepts behind Apache Kafka, the Kafka component architecture, and how Strimzi supports Kafka in a Kubernetes cluster.
The guide also describes how Strimzi _Operators_ help manage a deployment.

The guide contains high-level outlines of the processes required to deploy, configure, secure and monitor a deployment of Strimzi.

=== Deploying and Managing Strimzi

The _Deploying and Managing Strimzi_ guide provides instructions on all the options available for deploying, managing and upgrading Strimzi.
The guide describes what is deployed, and the order of deployment required to run Apache Kafka in a Kubernetes cluster.

As well as describing the deployment steps, the guide also provides pre- and post-deployment instructions to prepare for and verify a deployment.
Additional deployment options described include the steps to introduce metrics.

Examples that show how you might configure components are provided.  
For example, you might want to modify your deployment and introduce additional features, such as Cruise Control or distributed tracing.

Upgrade instructions are provided for Strimzi and Kafka upgrades.

=== Strimzi Custom Resource API Reference

The _Strimzi Custom Resource API Reference_ guide describes the configuration properties for custom resources.

The reference guide is built from two files.

.Strimzi Custom Resource API Reference files
[source,asciidoc,options="nowrap"]
----
\include::modules/con-common-configuration-properties.adoc[leveloffset=+1]
\include::modules/appendix_crds.adoc[]
----

The `con-common-configuration-properties.adoc` file contains descriptions of common configuration properties.
The content for the `documentation/modules/appendix_crds.adoc` file is generated directly from descriptions in the Java code.

Java files in the `api/` folder are annotated so that the descriptions are picked up in the build.

.Java annotations for documentation
[source,java,options="nowrap"]
----
import io.strimzi.crdgenerator.annotations.Description;
import io.strimzi.crdgenerator.annotations.DescriptionFile;
----

The tables in `appendix_crds.adoc` are built from `@Description` annotations in the Java files.

Additional information is included by adding:

. An `@DescriptionFile` annotation to the Java file
. A corresponding description file (`.adoc`) in the `documentation/api/` folder
. An `include:__DESCRIPTION-FILE-NAME__` reference to the `appendix_crds.adoc`

The `include:__DESCRIPTION-FILE-NAME__` reference is added automatically by the Maven build, so you do not need to add it manually.

For example, to add additional configuration for the `KafkaUserQuotas` custom resource:

. `api/src/main/java/io/strimzi/api/kafka/model/KafkaUserQuotas.java` contains:
** `import io.strimzi.crdgenerator.annotations.Description`
** `import io.strimzi.crdgenerator.annotations.DescriptionFile`
** `@Description("_descriptions for individual properties..._");`
** An `@DescriptionFile` annotation
. `documentation/api` includes the `io.strimzi.api.kafka.model.KafkaUserQuotas.adoc` file containing the additional configuration description.
+
The description file requires the same name as the related Java package.
. `appendix_crds.adoc` contains a reference to include the additional configuration description:
+
[source,asciidoc,options="nowrap"]
----
### `KafkaUserQuotas` schema reference

/include::../api/io.strimzi.api.kafka.model.user.KafkaUserQuotas.adoc[leveloffset=+1]
----

If you change anything in the `api` module of the Java code, you must rebuild the _Strimzi Custom Resource API Reference_ using a xref:make-tooling[make command].

== HTTP Bridge documentation

The HTTP Bridge documentation shows how to get started using the HTTP Bridge to make HTTP requests to a Kafka cluster.

The HTTP Bridge documentation is maintained in the https://github.com/strimzi/strimzi-kafka-bridge[HTTP Bridge project in GitHub].
For information on contributing to the HTTP Bridge documentation, see the https://github.com/strimzi/strimzi-kafka-bridge/blob/main/README.md[`readme`]  in the HTTP Bridge project.

== Quick start documentation

https://strimzi.io/quickstarts/[Strimzi quick starts] provide instructions for evaluating Strimzi using _Minikube_, _Kubernetes kind_, or _Docker Desktop_.
Steps describe how to deploy and run Strimzi as quickly as possible, with minimal configuration.

The quick starts are maintained in the https://github.com/strimzi/strimzi.github.io[Strimzi website project in GitHub].
For information on contributing to the quick starts, see the https://github.com/strimzi/strimzi.github.io/blob/main/README.md[`readme`] in the Strimzi website project.

---

### Documentation Contributing Make Tooling (`documentation/contributing/make-tooling.adoc`)

[[make-tooling]]
= Building the documentation locally

When you make changes to the documentation, it is a good practice to do a local test build to verify the book builds successfully and renders as you expect before you submit the merge request back to upstream main.

After you have made documentation updates in your local GitHub clone of the `strimzi-kafka-operator` project, you can build the documentation using AsciiDoctor or the `Makefile` provided with the project.

== Building documentation using AsciiDoctor

As the documentation is based on asciidoc, you can use AsciiDoctor to build the guides locally.
To build a guide using AsciiDoctor on your local machine, you run the `asciidoctor` command for the source file of the guide. 

For example, this command builds the Overview:

[source,shell]
----
asciidoctor 
----

== Building documentation with make commands

Use make commands from the root of the `strimzi-kafka-operator` project to build all the documentation at the same time.
The documentation is output to `documentation/html`.   

`make docu_clean`:: Deletes all temporary files
`make docu_check`:: Executes the documentation checks in `.azure/scripts/check_docs.sh`
`make docu_html`:: Generates HTML versions of all the guides
`make docu_htmlnoheader`:: Generates HTML versions of all the guides without the HTML headers so they are suitable for including in a website

NOTE: Before running the make commands, ensure that you remove any old build files from the documentation directories. 
Failure to do so will result in these files being included in the documentation checks and causing build failures. 
For instance, if you previously generated an HTML file in the `deploying` directory using Asciidoctor, make sure to delete that file.  

== Generating the Strimzi Custom Resource API Reference

The `documentation/modules/appendix_crds.adoc` file provides the main content for the _Strimzi Custom Resource API Reference_.
It is generated directly from the Java code when building the operators.

If you change the Strimzi API, you need to regenerate the API Reference before submitting your PR by running the following from the root:

[source,shell,subs=attributes+]
----
mvn clean -DskipTests install
make crd_install
----

The build uses https://github.com/mikefarah/yq[`yq`^], so make sure it is kept up-to-date for it to work properly.

NOTE: You only have to generate the _Strimzi Custom Resource API Reference_ if you changed anything in the `api` module of the Java code.

---

### Documentation Contributing Styleguide (`documentation/contributing/styleguide.adoc`)

[[conventions]]
= Documentation conventions

[[file-names]]
== File naming

Name each module file to match the module heading.  
Use dashes between words. Add a prefix with an underscore to indicate the module type:

* `snip-` for snippets
* `con-` for concepts
* `ref-` for references
* `proc-` for procedures
* `assembly-` for assemblies

.Examples
* `snip-intro-custom-resources`  (Snippet of reusable content)
* `con-pod-management.adoc`  (Concept module)
* `proc-creating-logging-filters.adoc`  (Procedure module)
* `ref-list-of-mirrormaker2-resources.adoc`  (Reference module)
* `assembly-deploy-kafka-cluster.adoc`  (Assembly of concepts and procedures)

See the link:https://redhat-documentation.github.io/modular-docs/[Modular Documentation Reference Guide^].

[[content_type]]
== (Required) Content type

Each file requires a content type defined at the top:

[source,asciidoc]
----
:_mod-docs-content-type: ASSEMBLY
:_mod-docs-content-type: PROCEDURE
:_mod-docs-content-type: CONCEPT
:_mod-docs-content-type: REFERENCE
:_mod-docs-content-type: SNIPPET
----

[[ids]]
== (Required) Anchor IDs

Each file requires an anchor ID.  
Use the same name as the file (with dashes) plus a _{context} variable:

[source]
----
[id='name-of-file_{context}']
= Module Heading

First sentence of module.
----

The context variable is defined in the assembly of a guide, such as `:context: str`.
Context variables allow reuse of the same content.
Anchor IDs allow cross-referencing. 
You can also add anchors to subheadings.

[NOTE]
.Other anchor formats (not recommended)
====
Other forms such as `\[[anchor-name]]` or `+[#anchor-name]+` exist, but they have limitations (for example, not supporting variables or certain characters). These can cause build errors. Always use `[id='name']`.
====

[[abstract]]
== (Required) Abstract

Start each file with an introductory paragraph.  
Mark it by adding a `[role="_abstract"]` tag above it.

[[headings-titles]]
== Headings and titles

Use sentence case for module, table, and figure headings.  
For example, _Secrets generated by the operators_, not _Secrets Generated By The Operators_.

[[config-styles]]
== Code and configuration examples

Provide code/configuration examples in AsciiDoc code blocks:

.Configuration example
[source,subs="+quotes"]
------
[source,yaml,subs="+quotes,attributes"] <1>
----
apiVersion: {KafkaApiVersion}
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
 replicas: *3* # \<1> <2>
 # ... <3>
----
------
<1> Source language is `yaml`. Use `subs` for attributes and formatting.  
<2> Use `#` before callout numbers so that the example is copy-friendly.  
<3> Use `# ...` for omitted lines.

[[replaceables]]
== User-replaced values

Style replaceables with angle brackets `< >`.  
For multi-word values, use underscores.  
Use monospace for commands or code.

.User-replaced values quick reference
[cols="50%,50%a",options="header"]
|===
|Value |Shows as
|<my_replaceable>|<my_replaceable>
|<my_code_replaceable>|`<my_code_replaceable>`
|===

TIP: In source blocks, add `subs="+quotes"` so replaceables render correctly.

[[links]]
== Links

Refer to top-level sections of books as chapters, not sections or topics.

.Links quick reference
[options="header"]
|===
|Link type |Use
|External links |\link:github.com[GitHub^]
|Internal links |\xref:doc_id[Section Title]
|===

NOTE: If you use `^` more than once in a paragraph, escape the first with a backslash.

[[images]]
== Images

Store images in `shared/images/`.  
Use this format to add an image to a section:

[source,asciidoc]
----
.Title of image
image:.png[<description_of_image>]
----

Inline images can be used in steps:

[source,asciidoc]
----
. My step
+
image:.png[<description_of_image>]
----

[[variables]]
== Variables

Variables are defined in `shared/attributes.adoc`.  
They allow single-source updates.  

For example, `:DefaultKafkaVersion:` sets the default Kafka version and `{DefaultKafkaVersion}` is used to insert it into configuration examples.

---

### Documentation Deploying Deploying (`documentation/deploying/deploying.adoc`)

:experimental:
include::shared/attributes.adoc[]

:context: str

[id="deploying-book_{context}"]
= Deploying and Managing Strimzi

//Introduction to the install process
include::assemblies/deploying/assembly-deploy-intro.adoc[leveloffset=+1]
//Using Kafka in Kraft mode
include::assemblies/deploying/assembly-kraft-mode.adoc[leveloffset=+1]
//Install options
include::modules/deploying/con-strimzi-installation-methods.adoc[leveloffset=+1]
//Deployment path
include::modules/deploying/con-deploy-paths.adoc[leveloffset=+1]
//How to access release artifacts
include::modules/deploying/con-deploy-product-downloads.adoc[leveloffset=+1]
//Prep for the deployment
include::assemblies/deploying/assembly-deploy-tasks-prep.adoc[leveloffset=+1]
//Deployment steps using installation artifacts
include::assemblies/deploying/assembly-deploy-tasks.adoc[leveloffset=+1]
//Deployment using operatorhub.io
include::modules/deploying/con-deploy-cluster-operator-from-operator-hub.adoc[leveloffset=+1]
//Deployment using Helm
include::modules/deploying/proc-deploy-cluster-operator-helm-chart.adoc[leveloffset=+1]
//feature gates
include::modules/operators/ref-operator-cluster-feature-gates.adoc[leveloffset=+1]
//configuration of components
include::assemblies/configuring/assembly-config.adoc[leveloffset=+1]
//creating topics
include::assemblies/operators/assembly-using-the-topic-operator.adoc[leveloffset=+1]
//creating users
include::assemblies/operators/assembly-using-the-user-operator.adoc[leveloffset=+1]
//using the access-operator
ifdef::Section[]
include::assemblies/security/assembly-access-operator.adoc[leveloffset=+1]
endif::Section[]
//Verifying the deployment and providing access to an external client
include::assemblies/deploying/assembly-deploy-client-access.adoc[leveloffset=+1]
//Securing the deployment
include::assemblies/security/assembly-securing-access.adoc[leveloffset=+1]
//using OAuth
include::assemblies/oauth/assembly-oauth-security.adoc[leveloffset=+1]
//managing tls certificates
include::assemblies/security/assembly-security.adoc[leveloffset=+1]
//security context for all pods
include::assemblies/configuring/assembly-security-providers.adoc[leveloffset=+1]
//Scaling clusters
include::assemblies/configuring/assembly-scaling-kafka-clusters.adoc[leveloffset=+1]
//Using Cruise Control for rebalancing
include::assemblies/cruise-control/assembly-cruise-control-concepts.adoc[leveloffset=+1]
//Using Cruise Control for changing topic replication factor
include::modules/cruise-control/proc-cruise-control-topic-replication.adoc[leveloffset=+1]
//Using Cruise Control to move data on jbod disks
include::modules/cruise-control/proc-cruise-control-moving-data.adoc[leveloffset=+1]
//Using the reassign tool to change topic replicas
include::assemblies/configuring/assembly-reassign-tool.adoc[leveloffset=+1]
//Introduce metrics and monitoring to your deployment
include::assemblies/metrics/assembly-metrics.adoc[leveloffset=+1]
//Introduce tracing to your deployment
include::assemblies/tracing/assembly-distributed-tracing.adoc[leveloffset=+1]
//using drain cleaner to drain pods
include::assemblies/deploying/assembly-drain-cleaner.adoc[leveloffset=+1]
//Managing rolling updates
include::assemblies/deploying/assembly-rolling-updates.adoc[leveloffset=+1]
//How to monitor restart events
include::assemblies/deploying/assembly-deploy-restart-events.adoc[leveloffset=+1]
//Upgrading the deployment
include::assemblies/upgrading/assembly-upgrade.adoc[leveloffset=+1]
//Downgrading the deployment
include::assemblies/upgrading/assembly-downgrade.adoc[leveloffset=+1]
//uninstalling the product
include::assemblies/deploying/assembly-uninstalling.adoc[leveloffset=+1]
//recovering from PVs
include::assemblies/deploying/assembly-cluster-recovery-volume.adoc[leveloffset=+1]
//tuning configuration
include::assemblies/tuning/assembly-tuning-config.adoc[leveloffset=+1]

---

### Documentation Glossary Glossary (`documentation/glossary/glossary.adoc`)

:experimental:
include::shared/attributes.adoc[]
//turns off numbering
:sectnums!:

:context: str

[id="glossary-book_{context}"]
= Strimzi Glossary

[role="_abstract"]
This glossary explains terminology unique to Strimzi and its components. 
It supports consistent usage and understanding across Strimzi documentation. 
Terms from Kafka and Kubernetes are outside its scope.

//glossary entries
include::modules/glossary/a.adoc[leveloffset=+1]
include::modules/glossary/c.adoc[leveloffset=+1]
include::modules/glossary/d.adoc[leveloffset=+1]
include::modules/glossary/e.adoc[leveloffset=+1]
include::modules/glossary/f.adoc[leveloffset=+1]
include::modules/glossary/k.adoc[leveloffset=+1]
include::modules/glossary/l.adoc[leveloffset=+1]
include::modules/glossary/m.adoc[leveloffset=+1]
include::modules/glossary/n.adoc[leveloffset=+1]
include::modules/glossary/s.adoc[leveloffset=+1]
include::modules/glossary/t.adoc[leveloffset=+1]
include::modules/glossary/u.adoc[leveloffset=+1]

---

### Documentation Modules Appendix Crds (`documentation/modules/appendix_crds.adoc`)

:_mod-docs-content-type: REFERENCE

// This file is auto-generated by io.strimzi.crdgenerator.DocGenerator.
// To change this documentation you need to edit the Java sources.

[id='type-Kafka-{context}']
= `Kafka` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaSpec-{context}[`KafkaSpec`]
|The specification of the Kafka cluster.
|status
|xref:type-KafkaStatus-{context}[`KafkaStatus`]
|The status of the Kafka cluster.
|====

[id='type-KafkaSpec-{context}']
= `KafkaSpec` schema reference

Used in: xref:type-Kafka-{context}[`Kafka`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|kafka
|xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]
|Configuration of the Kafka cluster.
|entityOperator
|xref:type-EntityOperatorSpec-{context}[`EntityOperatorSpec`]
|Configuration of the Entity Operator.
|clusterCa
|xref:type-CertificateAuthority-{context}[`CertificateAuthority`]
|Configuration of the cluster certificate authority.
|clientsCa
|xref:type-CertificateAuthority-{context}[`CertificateAuthority`]
|Configuration of the clients certificate authority.
|cruiseControl
|xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`]
|Configuration for Cruise Control deployment. Deploys a Cruise Control instance when specified.
|kafkaExporter
|xref:type-KafkaExporterSpec-{context}[`KafkaExporterSpec`]
|Configuration of the Kafka Exporter. Kafka Exporter can provide additional metrics, for example lag of consumer group at topic/partition.
|maintenanceTimeWindows
|string array
|A list of time windows for maintenance tasks (that is, certificates renewal). Each time window is defined by a cron expression.
|====

[id='type-KafkaClusterSpec-{context}']
= `KafkaClusterSpec` schema reference

Used in: xref:type-KafkaSpec-{context}[`KafkaSpec`]

xref:type-KafkaClusterSpec-schema-{context}[Full list of `KafkaClusterSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.KafkaClusterSpec.adoc[leveloffset=+1]

[id='type-KafkaClusterSpec-schema-{context}']
== `KafkaClusterSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|version
|string
|The Kafka broker version. Defaults to the latest version. Consult the user documentation to understand the process required to upgrade or downgrade the version.
|metadataVersion
|string
|Added in Strimzi 0.39.0. The KRaft metadata version used by the Kafka cluster. This property is ignored when running in ZooKeeper mode. If the property is not set, it defaults to the metadata version that corresponds to the `version` property.
|image
|string
|The container image used for Kafka pods. If the property is not set, the default Kafka image version is determined based on the `version` configuration. The image names are specifically mapped to corresponding versions in the Cluster Operator configuration. Changing the Kafka image version does not automatically update the image versions for other components, such as Kafka Exporter. 
|listeners
|xref:type-GenericKafkaListener-{context}[`GenericKafkaListener`] array
|Configures listeners to provide access to Kafka brokers.
|config
|map
|Kafka broker config properties with certain prefixes cannot be set unless it is in the exception list. Consult the documentation for the list of forbidden prefixes and exceptions.
|authorization
|xref:type-KafkaAuthorizationSimple-{context}[`KafkaAuthorizationSimple`], xref:type-KafkaAuthorizationCustom-{context}[`KafkaAuthorizationCustom`]
|Authorization configuration for Kafka brokers.
|rack
|xref:type-TopologyLabelRack-{context}[`TopologyLabelRack`], xref:type-EnvironmentVariableRack-{context}[`EnvironmentVariableRack`]
|Configuration of the `broker.rack` broker config.
|brokerRackInitImage
|string
|The image of the init container used for initializing the `broker.rack`.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|jmxOptions
|xref:type-KafkaJmxOptions-{context}[`KafkaJmxOptions`]
|JMX Options for Kafka brokers.
|metricsConfig
|xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`], xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]
|Metrics configuration.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration for Kafka.
|template
|xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`]
|Template for Kafka cluster resources. The template allows users to specify how the Kubernetes resources are generated.
|tieredStorage
|xref:type-TieredStorageCustom-{context}[`TieredStorageCustom`]
|Configure the tiered storage feature for Kafka brokers.
|quotas
|xref:type-QuotasPluginKafka-{context}[`QuotasPluginKafka`], xref:type-QuotasPluginStrimzi-{context}[`QuotasPluginStrimzi`]
|Quotas plugin configuration for Kafka brokers allows setting quotas for disk usage, produce/fetch rates, and more. Supported plugin types include `kafka` (default) and `strimzi`. If not specified, the default `kafka` quotas plugin is used.
|====

[id='type-GenericKafkaListener-{context}']
= `GenericKafkaListener` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]

xref:type-GenericKafkaListener-schema-{context}[Full list of `GenericKafkaListener` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListener.adoc[leveloffset=+1]

[id='type-GenericKafkaListener-schema-{context}']
== `GenericKafkaListener` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|Name of the listener. The name will be used to identify the listener and the related Kubernetes objects. The name has to be unique within given a Kafka cluster. The name can consist of lowercase characters and numbers and be up to 11 characters long.
|port
|integer
|Port number used by the listener inside Kafka. The port number has to be unique within a given Kafka cluster. Allowed port numbers are 9092 and higher with the exception of ports 9404 and 9999, which are already used for Prometheus and JMX. Depending on the listener type, the port number might not be the same as the port number that connects Kafka clients.
|type
|string (one of [ingress, internal, route, loadbalancer, cluster-ip, nodeport, tlsroute])
|Type of the listener. The supported types are as follows: 

* `internal` type exposes Kafka internally only within the Kubernetes cluster.
* `route` type uses OpenShift Routes to expose Kafka.
* `loadbalancer` type uses LoadBalancer type services to expose Kafka.
* `nodeport` type uses NodePort type services to expose Kafka.
* `ingress` (deprecated) type uses Kubernetes Nginx Ingress to expose Kafka with TLS passthrough.
* `cluster-ip` type uses a per-broker `ClusterIP` service.

|tls
|boolean
|Enables TLS encryption on the listener. This is a required property. For `route` and `ingress` type listeners, TLS encryption must be always enabled.
|authentication
|xref:type-KafkaListenerAuthenticationTls-{context}[`KafkaListenerAuthenticationTls`], xref:type-KafkaListenerAuthenticationScramSha512-{context}[`KafkaListenerAuthenticationScramSha512`], xref:type-KafkaListenerAuthenticationCustom-{context}[`KafkaListenerAuthenticationCustom`]
|Authentication configuration for this listener.
|configuration
|xref:type-GenericKafkaListenerConfiguration-{context}[`GenericKafkaListenerConfiguration`]
|Additional listener configuration.
|networkPolicyPeers
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#networkpolicypeer-v1-networking-k8s-io[NetworkPolicyPeer] array
|List of peers which should be able to connect to this listener. Peers in this list are combined using a logical OR operation. If this field is empty or missing, all connections will be allowed for this listener. If this field is present and contains at least one item, the listener only allows the traffic which matches at least one item in this list.
|====

[id='type-KafkaListenerAuthenticationTls-{context}']
= `KafkaListenerAuthenticationTls` schema reference

Used in: xref:type-GenericKafkaListener-{context}[`GenericKafkaListener`]


The `type` property is a discriminator that distinguishes use of the `KafkaListenerAuthenticationTls` type from xref:type-KafkaListenerAuthenticationScramSha512-{context}[`KafkaListenerAuthenticationScramSha512`], xref:type-KafkaListenerAuthenticationCustom-{context}[`KafkaListenerAuthenticationCustom`].
It must have the value `tls` for the type `KafkaListenerAuthenticationTls`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `tls`.
|====

[id='type-KafkaListenerAuthenticationScramSha512-{context}']
= `KafkaListenerAuthenticationScramSha512` schema reference

Used in: xref:type-GenericKafkaListener-{context}[`GenericKafkaListener`]


The `type` property is a discriminator that distinguishes use of the `KafkaListenerAuthenticationScramSha512` type from xref:type-KafkaListenerAuthenticationTls-{context}[`KafkaListenerAuthenticationTls`], xref:type-KafkaListenerAuthenticationCustom-{context}[`KafkaListenerAuthenticationCustom`].
It must have the value `scram-sha-512` for the type `KafkaListenerAuthenticationScramSha512`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `scram-sha-512`.
|====

[id='type-KafkaListenerAuthenticationCustom-{context}']
= `KafkaListenerAuthenticationCustom` schema reference

Used in: xref:type-GenericKafkaListener-{context}[`GenericKafkaListener`]

xref:type-KafkaListenerAuthenticationCustom-schema-{context}[Full list of `KafkaListenerAuthenticationCustom` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.listener.KafkaListenerAuthenticationCustom.adoc[leveloffset=+1]

[id='type-KafkaListenerAuthenticationCustom-schema-{context}']
== `KafkaListenerAuthenticationCustom` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaListenerAuthenticationCustom` type from xref:type-KafkaListenerAuthenticationTls-{context}[`KafkaListenerAuthenticationTls`], xref:type-KafkaListenerAuthenticationScramSha512-{context}[`KafkaListenerAuthenticationScramSha512`].
It must have the value `custom` for the type `KafkaListenerAuthenticationCustom`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `custom`.
|sasl
|boolean
|Enable or disable SASL on this listener.
|listenerConfig
|map
|Configuration to be used for a specific listener. All values are prefixed with `listener.name.<listener_name>`.
|====

[id='type-GenericKafkaListenerConfiguration-{context}']
= `GenericKafkaListenerConfiguration` schema reference

Used in: xref:type-GenericKafkaListener-{context}[`GenericKafkaListener`]

xref:type-GenericKafkaListenerConfiguration-schema-{context}[Full list of `GenericKafkaListenerConfiguration` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfiguration.adoc[leveloffset=+1]

[id='type-GenericKafkaListenerConfiguration-schema-{context}']
== `GenericKafkaListenerConfiguration` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|brokerCertChainAndKey
|xref:type-CertAndKeySecretSource-{context}[`CertAndKeySecretSource`]
|Reference to the `Secret` which holds the certificate and private key pair which will be used for this listener. The certificate can optionally contain the whole chain. This field can be used only with listeners with enabled TLS encryption.
|class
|string
|Configures a specific class for `Ingress` and `LoadBalancer` that defines which controller is used. If not specified, the default controller is used.

* For an `ingress` listener, the operator uses this property to set the `ingressClassName` property in the `Ingress` resources.
* For a `loadbalancer` listener, the operator uses this property to set the `loadBalancerClass` property  in the `Service` resources.

For `ingress` and `loadbalancer` listeners only.
|externalTrafficPolicy
|string (one of [Local, Cluster])
|Specifies whether the service routes external traffic to cluster-wide or node-local endpoints:

* `Cluster` may cause a second hop to another node and obscures the client source IP.
* `Local` avoids a second hop for `LoadBalancer` and `Nodeport` type services and preserves the client source IP (when supported by the infrastructure).

If unspecified, Kubernetes uses `Cluster` as the default. For `loadbalancer` or `nodeport` listeners only.
|loadBalancerSourceRanges
|string array
|A list of CIDR ranges (for example `10.0.0.0/8` or `130.211.204.1/32`) from which clients can connect to loadbalancer listeners. If supported by the platform, traffic through the loadbalancer is restricted to the specified CIDR ranges. This field is applicable only for loadbalancer type services and is ignored if the cloud provider does not support the feature. For `loadbalancer` listeners only.
|bootstrap
|xref:type-GenericKafkaListenerConfigurationBootstrap-{context}[`GenericKafkaListenerConfigurationBootstrap`]
|Bootstrap configuration.
|brokers
|xref:type-GenericKafkaListenerConfigurationBroker-{context}[`GenericKafkaListenerConfigurationBroker`] array
|Per-broker configurations.
|ipFamilyPolicy
|string (one of [RequireDualStack, SingleStack, PreferDualStack])
|Specifies the IP Family Policy used by the service. Available options are `SingleStack`, `PreferDualStack` and `RequireDualStack`:

* `SingleStack` is for a single IP family.
* `PreferDualStack` is for two IP families on dual-stack configured clusters or a single IP family on single-stack clusters.
* `RequireDualStack` fails unless there are two IP families on dual-stack configured clusters.

If unspecified, Kubernetes will choose the default value based on the service type.
|ipFamilies
|string (one or more of [IPv6, IPv4]) array
|Specifies the IP Families used by the service. Available options are `IPv4` and `IPv6`. If unspecified, Kubernetes will choose the default value based on the `ipFamilyPolicy` setting.
|createBootstrapService
|boolean
|Whether to create the bootstrap service or not. The bootstrap service is created by default (if not specified differently). This field can be used with the `loadbalancer` listener.
|finalizers
|string array
|A list of finalizers configured for the `LoadBalancer` type services created for this listener. If supported by the platform, the finalizer `service.kubernetes.io/load-balancer-cleanup` to make sure that the external load balancer is deleted together with the service.For more information, see https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#garbage-collecting-load-balancers. For `loadbalancer` listeners only.
|useServiceDnsDomain
|boolean
|Configures whether the Kubernetes service DNS domain should be included in the generated addresses.

* If set to `false`, the generated addresses do not contain the service DNS domain suffix. For example, `my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc`.
* If set to `true`, the generated addresses contain the service DNS domain suffix. For example, `my-cluster-kafka-0.my-cluster-kafka-brokers.myproject.svc.cluster.local`.

The default is `.cluster.local`, but this is customizable using the environment variable `KUBERNETES_SERVICE_DNS_DOMAIN`. For `internal` and `cluster-ip` listeners only.
|maxConnections
|integer
|The maximum number of connections we allow for this listener in the broker at any time. New connections are blocked if the limit is reached.
|maxConnectionCreationRate
|integer
|The maximum connection creation rate we allow in this listener at any time. New connections will be throttled if the limit is reached.
|preferredNodePortAddressType
|string (one of [ExternalDNS, ExternalIP, Hostname, InternalIP, InternalDNS])
|Defines which address type should be used as the node address. Available types are: `ExternalDNS`, `ExternalIP`, `InternalDNS`, `InternalIP` and `Hostname`. By default, the addresses are used in the following order (the first one found is used):

* `ExternalDNS`
* `ExternalIP`
* `InternalDNS`
* `InternalIP`
* `Hostname`

This property is used to select the preferred address type, which is checked first. If no address is found for this address type, the other types are checked in the default order. For `nodeport` listeners only.
|publishNotReadyAddresses
|boolean
|Configures whether the service endpoints are considered "ready" even if the Pods themselves are not. Defaults to `false`. This field can not be used with `internal` listeners.
|perBrokerAnnotationsTemplate
|map
|Configures the template used to generate annotations for individual brokers. You can use the `{nodeId}` and `{nodePodName}` placeholders in annotation values. Templating applies only to annotation values.
|perBrokerLabelsTemplate
|map
|Configures the template used to generate labels for individual brokers. You can use the `{nodeId}` and `{nodePodName}` placeholders in label values. Templating applies only to label values.
|hostTemplate
|string
|Configures the template for generating the hostnames of the individual brokers. Valid placeholders that you can use in the template are `{nodeId}` and `{nodePodName}`.
|advertisedHostTemplate
|string
|Configures the template for generating the advertised hostnames of the individual brokers. Valid placeholders that you can use in the template are `{nodeId}` and `{nodePodName}`.
|advertisedPortTemplate
|string
|Configures the template for generating the advertised ports of the individual brokers. It allows to specify a simple mathematics formula that will be used to calculate the port. The only valid placeholder that you can use in the template is `{nodeId}`. Supported operations are `+`, `-`, and `*`. For example, `9000 + {nodeId}` will generate ports `9000`, `9001`, `9002`, and so on for the individual brokers. You can also use a fixed port number in the template, for example `9000`, which will generate the same port for all brokers.
|allocateLoadBalancerNodePorts
|boolean
|Configures whether to allocate NodePort automatically for the `Service` with type `LoadBalancer`.
This is a one to one with the `spec.allocateLoadBalancerNodePorts` configuration in the `Service` type
For `loadbalancer` listeners only.
|parentRefs
|https://gateway-api.sigs.k8s.io/reference/api-spec/1.5/spec/#parentreference[ParentReference] array
|For `tlsroute` listeners only.
Configures the Gateway API resource or resources that generated `TLSRoute` resources attach to.
Typically, this is a `Gateway` resource.
|====

[id='type-CertAndKeySecretSource-{context}']
= `CertAndKeySecretSource` schema reference

Used in: xref:type-GenericKafkaListenerConfiguration-{context}[`GenericKafkaListenerConfiguration`], xref:type-KafkaBridgeHttpTls-{context}[`KafkaBridgeHttpTls`], xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretName
|string
|The name of the Secret containing the certificate.
|certificate
|string
|The name of the file certificate in the Secret.
|key
|string
|The name of the private key in the secret. The private key must be in unencrypted PKCS #8 format. For more information, see RFC 5208: https://datatracker.ietf.org/doc/html/rfc5208.
|====

[id='type-GenericKafkaListenerConfigurationBootstrap-{context}']
= `GenericKafkaListenerConfigurationBootstrap` schema reference

Used in: xref:type-GenericKafkaListenerConfiguration-{context}[`GenericKafkaListenerConfiguration`]

xref:type-GenericKafkaListenerConfigurationBootstrap-schema-{context}[Full list of `GenericKafkaListenerConfigurationBootstrap` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfigurationBootstrap.adoc[leveloffset=+1]

[id='type-GenericKafkaListenerConfigurationBootstrap-schema-{context}']
== `GenericKafkaListenerConfigurationBootstrap` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|alternativeNames
|string array
|Additional alternative names for the bootstrap service. The alternative names will be added to the list of subject alternative names of the TLS certificates.
|host
|string
|Specifies the hostname used for the bootstrap resource. For `route` (optional) or `ingress` (required) listeners only. Ensure the hostname resolves to the Ingress endpoints; no validation is performed by Strimzi.
|nodePort
|integer
|Node port for the bootstrap service. For `nodeport` listeners only.
|loadBalancerIP
|string
|The loadbalancer is requested with the IP address specified in this property. This feature depends on whether the underlying cloud provider supports specifying the `loadBalancerIP` when a load balancer is created. This property is ignored if the cloud provider does not support the feature. For `loadbalancer` listeners only.
|annotations
|map
|Annotations added to `Ingress`, `Route`, or `Service` resources. You can use this property to configure DNS providers such as External DNS. For `loadbalancer`, `nodeport`, `route`, or `ingress` listeners only.
|labels
|map
|Labels added to `Ingress`, `Route`, or `Service` resources. For `loadbalancer`, `nodeport`, `route`, or `ingress` listeners only.
|externalIPs
|string array
|External IPs associated to the nodeport service. These IPs are used by clients external to the Kubernetes cluster to access the Kafka brokers. This property is helpful when `nodeport` without `externalIP` is not sufficient. For example on bare-metal Kubernetes clusters that do not support Loadbalancer service types. For `nodeport` listeners only.
|====

[id='type-GenericKafkaListenerConfigurationBroker-{context}']
= `GenericKafkaListenerConfigurationBroker` schema reference

Used in: xref:type-GenericKafkaListenerConfiguration-{context}[`GenericKafkaListenerConfiguration`]

xref:type-GenericKafkaListenerConfigurationBroker-schema-{context}[Full list of `GenericKafkaListenerConfigurationBroker` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.listener.GenericKafkaListenerConfigurationBroker.adoc[leveloffset=+1]

[id='type-GenericKafkaListenerConfigurationBroker-schema-{context}']
== `GenericKafkaListenerConfigurationBroker` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|broker
|integer
|ID of the kafka broker (broker identifier). Broker IDs start from 0 and correspond to the number of broker replicas.
|advertisedHost
|string
|The host name used in the brokers' `advertised.listeners`.
|advertisedPort
|integer
|The port number used in the brokers' `advertised.listeners`.
|host
|string
|The broker host. This field will be used in the Ingress resource or in the Route resource to specify the desired hostname. This field can be used only with `route` (optional) or `ingress` (required) type listeners.
|nodePort
|integer
|Node port for the per-broker service. This field can be used only with `nodeport` type listener.
|loadBalancerIP
|string
|The loadbalancer is requested with the IP address specified in this field. This feature depends on whether the underlying cloud provider supports specifying the `loadBalancerIP` when a load balancer is created. This field is ignored if the cloud provider does not support the feature.This field can be used only with `loadbalancer` type listener.
|annotations
|map
|Annotations that will be added to the `Ingress` or `Service` resource. You can use this field to configure DNS providers such as External DNS. This field can be used only with `loadbalancer`, `nodeport`, or `ingress` type listeners.
|labels
|map
|Labels that will be added to the `Ingress`, `Route`, or `Service` resource. This field can be used only with `loadbalancer`, `nodeport`, `route`, or `ingress` type listeners.
|externalIPs
|string array
|External IPs associated to the nodeport service. These IPs are used by clients external to the Kubernetes cluster to access the Kafka brokers. This field is helpful when `nodeport` without `externalIP` is not sufficient. For example on bare-metal Kubernetes clusters that do not support Loadbalancer service types. This field can only be used with `nodeport` type listener.
|====

[id='type-KafkaAuthorizationSimple-{context}']
= `KafkaAuthorizationSimple` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]

xref:type-KafkaAuthorizationSimple-schema-{context}[Full list of `KafkaAuthorizationSimple` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.KafkaAuthorizationSimple.adoc[leveloffset=+1]

[id='type-KafkaAuthorizationSimple-schema-{context}']
== `KafkaAuthorizationSimple` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaAuthorizationSimple` type from xref:type-KafkaAuthorizationCustom-{context}[`KafkaAuthorizationCustom`].
It must have the value `simple` for the type `KafkaAuthorizationSimple`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `simple`.
|superUsers
|string array
|List of super users. Should contain list of user principals which should get unlimited access rights.
|====

[id='type-KafkaAuthorizationCustom-{context}']
= `KafkaAuthorizationCustom` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]

xref:type-KafkaAuthorizationCustom-schema-{context}[Full list of `KafkaAuthorizationCustom` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.KafkaAuthorizationCustom.adoc[leveloffset=+1]

[id='type-KafkaAuthorizationCustom-schema-{context}']
== `KafkaAuthorizationCustom` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaAuthorizationCustom` type from xref:type-KafkaAuthorizationSimple-{context}[`KafkaAuthorizationSimple`].
It must have the value `custom` for the type `KafkaAuthorizationCustom`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `custom`.
|authorizerClass
|string
|Authorization implementation class, which must be available in classpath.
|superUsers
|string array
|List of super users, which are user principals with unlimited access rights.
|supportsAdminApi
|boolean
|Indicates whether the custom authorizer supports the APIs for managing ACLs using the Kafka Admin API. Defaults to `false`.
|====

[id='type-TopologyLabelRack-{context}']
= `TopologyLabelRack` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]

xref:type-TopologyLabelRack-schema-{context}[Full list of `TopologyLabelRack` schema properties]

include::../api/io.strimzi.api.kafka.model.common.TopologyLabelRack.adoc[leveloffset=+1]

[id='type-TopologyLabelRack-schema-{context}']
== `TopologyLabelRack` schema properties


The `type` property is a discriminator that distinguishes use of the `TopologyLabelRack` type from xref:type-EnvironmentVariableRack-{context}[`EnvironmentVariableRack`].
It must have the value `topology-label` for the type `TopologyLabelRack`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `topology-label`.
|topologyKey
|string
|A key that matches labels assigned to the Kubernetes cluster nodes. The value of the label is used to set a broker's `broker.rack` config, and the `client.rack` config for Kafka Connect or MirrorMaker 2.
|====

[id='type-EnvironmentVariableRack-{context}']
= `EnvironmentVariableRack` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]

xref:type-EnvironmentVariableRack-schema-{context}[Full list of `EnvironmentVariableRack` schema properties]

include::../api/io.strimzi.api.kafka.model.common.EnvironmentVariableRack.adoc[leveloffset=+1]

[id='type-EnvironmentVariableRack-schema-{context}']
== `EnvironmentVariableRack` schema properties


The `type` property is a discriminator that distinguishes use of the `EnvironmentVariableRack` type from xref:type-TopologyLabelRack-{context}[`TopologyLabelRack`].
It must have the value `environment-variable` for the type `EnvironmentVariableRack`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `environment-variable`.
|envVarName
|string
|The name of the environment variable that defines the rack ID. Its value sets the `broker.rack` configuration for Kafka brokers and the `client.rack` configuration for Kafka Connect or MirrorMaker 2.
|====

[id='type-StrimziProbe-{context}']
= `StrimziProbe` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-EntityTopicOperatorSpec-{context}[`EntityTopicOperatorSpec`], xref:type-EntityUserOperatorSpec-{context}[`EntityUserOperatorSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaExporterSpec-{context}[`KafkaExporterSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|initialDelaySeconds
|integer
|The initial delay before first the health is first checked. Default to 15 seconds. Minimum value is 0.
|timeoutSeconds
|integer
|The timeout for each attempted health check. Default to 5 seconds. Minimum value is 1.
|periodSeconds
|integer
|How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1.
|successThreshold
|integer
|Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness. Minimum value is 1.
|failureThreshold
|integer
|Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1.
|====

[id='type-JvmOptions-{context}']
= `JvmOptions` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-EntityTopicOperatorSpec-{context}[`EntityTopicOperatorSpec`], xref:type-EntityUserOperatorSpec-{context}[`EntityUserOperatorSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`], xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|-XX
|map
|A map of -XX options to the JVM.
|-Xmx
|string
|-Xmx option to to the JVM.
|-Xms
|string
|-Xms option to to the JVM.
|gcLoggingEnabled
|boolean
|Specifies whether the Garbage Collection logging is enabled. The default is false.
|javaSystemProperties
|xref:type-SystemProperty-{context}[`SystemProperty`] array
|A map of additional system properties which will be passed using the `-D` option to the JVM.
|====

[id='type-SystemProperty-{context}']
= `SystemProperty` schema reference

Used in: xref:type-JvmOptions-{context}[`JvmOptions`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The system property name.
|value
|string
|The system property value.
|====

[id='type-KafkaJmxOptions-{context}']
= `KafkaJmxOptions` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]

xref:type-KafkaJmxOptions-schema-{context}[Full list of `KafkaJmxOptions` schema properties]

include::../api/io.strimzi.api.kafka.model.common.jmx.KafkaJmxOptions.adoc[leveloffset=+1]

[id='type-KafkaJmxOptions-schema-{context}']
== `KafkaJmxOptions` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|authentication
|xref:type-KafkaJmxAuthenticationPassword-{context}[`KafkaJmxAuthenticationPassword`]
|Authentication configuration for connecting to the JMX port.
|====

[id='type-KafkaJmxAuthenticationPassword-{context}']
= `KafkaJmxAuthenticationPassword` schema reference

Used in: xref:type-KafkaJmxOptions-{context}[`KafkaJmxOptions`]


The `type` property is a discriminator that distinguishes use of the `KafkaJmxAuthenticationPassword` type from other subtypes that may be added in the future.
It must have the value `password` for the type `KafkaJmxAuthenticationPassword`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `password`.
|====

[id='type-JmxPrometheusExporterMetrics-{context}']
= `JmxPrometheusExporterMetrics` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


The `type` property is a discriminator that distinguishes use of the `JmxPrometheusExporterMetrics` type from xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`].
It must have the value `jmxPrometheusExporter` for the type `JmxPrometheusExporterMetrics`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `jmxPrometheusExporter`.
|valueFrom
|xref:type-ExternalConfigurationReference-{context}[`ExternalConfigurationReference`]
|ConfigMap entry where the Prometheus JMX Exporter configuration is stored.
|====

[id='type-ExternalConfigurationReference-{context}']
= `ExternalConfigurationReference` schema reference

Used in: xref:type-ExternalLogging-{context}[`ExternalLogging`], xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|configMapKeyRef
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#configmapkeyselector-v1-core[ConfigMapKeySelector]
|Reference to the key in the ConfigMap containing the configuration.
|====

[id='type-StrimziMetricsReporter-{context}']
= `StrimziMetricsReporter` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


The `type` property is a discriminator that distinguishes use of the `StrimziMetricsReporter` type from xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`].
It must have the value `strimziMetricsReporter` for the type `StrimziMetricsReporter`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `strimziMetricsReporter`.
|values
|xref:type-StrimziMetricsReporterValues-{context}[`StrimziMetricsReporterValues`]
|Configuration values for the Strimzi Metrics Reporter.
|====

[id='type-StrimziMetricsReporterValues-{context}']
= `StrimziMetricsReporterValues` schema reference

Used in: xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|allowList
|string array
|A list of regex patterns to filter the metrics to collect. Should contain at least one element.
|====

[id='type-InlineLogging-{context}']
= `InlineLogging` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-EntityTopicOperatorSpec-{context}[`EntityTopicOperatorSpec`], xref:type-EntityUserOperatorSpec-{context}[`EntityUserOperatorSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


The `type` property is a discriminator that distinguishes use of the `InlineLogging` type from xref:type-ExternalLogging-{context}[`ExternalLogging`].
It must have the value `inline` for the type `InlineLogging`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `inline`.
|loggers
|map
|A Map from logger name to logger level.
|====

[id='type-ExternalLogging-{context}']
= `ExternalLogging` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`], xref:type-EntityTopicOperatorSpec-{context}[`EntityTopicOperatorSpec`], xref:type-EntityUserOperatorSpec-{context}[`EntityUserOperatorSpec`], xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


The `type` property is a discriminator that distinguishes use of the `ExternalLogging` type from xref:type-InlineLogging-{context}[`InlineLogging`].
It must have the value `external` for the type `ExternalLogging`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `external`.
|valueFrom
|xref:type-ExternalConfigurationReference-{context}[`ExternalConfigurationReference`]
|`ConfigMap` entry where the logging configuration is stored. 
|====

[id='type-KafkaClusterTemplate-{context}']
= `KafkaClusterTemplate` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|pod
|xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]
|Template for Kafka `Pods`.
|bootstrapService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for Kafka bootstrap `Service`.
|brokersService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for Kafka broker `Service`.
|externalBootstrapService
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka external bootstrap `Service`.
|perPodService
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Services` used for access from outside of Kubernetes.
|externalBootstrapRoute
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka external bootstrap `Route`.
|perPodRoute
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Routes` used for access from outside of OpenShift.
|externalBootstrapIngress
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka external bootstrap `Ingress`.
|perPodIngress
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Ingress` used for access from outside of Kubernetes.
|persistentVolumeClaim
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for all Kafka `PersistentVolumeClaims`.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for Kafka `PodDisruptionBudget`.
|kafkaContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka broker container.
|initContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka init container.
|clusterCaCert
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Secret with Kafka Cluster certificate public key.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka service account.
|jmxSecret
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Secret of the Kafka Cluster JMX authentication.
|clusterRoleBinding
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka ClusterRoleBinding.
|podSet
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka `StrimziPodSet` resource.
|====

[id='type-StatefulPodTemplate-{context}']
= `StatefulPodTemplate` schema reference

Used in: xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`], xref:type-KafkaNodePoolTemplate-{context}[`KafkaNodePoolTemplate`]

xref:type-StatefulPodTemplate-schema-{context}[Full list of `StatefulPodTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.StatefulPodTemplate.adoc[leveloffset=+1]

[id='type-StatefulPodTemplate-schema-{context}']
== `StatefulPodTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata applied to the resource.
|imagePullSecrets
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#localobjectreference-v1-core[LocalObjectReference] array
|List of references to secrets in the same namespace to use for pulling any of the images used by this Pod. When the `STRIMZI_IMAGE_PULL_SECRETS` environment variable in Cluster Operator and the `imagePullSecrets` option are specified, only the `imagePullSecrets` variable is used and the `STRIMZI_IMAGE_PULL_SECRETS` variable is ignored.
|securityContext
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#podsecuritycontext-v1-core[PodSecurityContext]
|Configures pod-level security attributes and common container settings.
|terminationGracePeriodSeconds
|integer
|The grace period is the duration in seconds after the processes running in the pod are sent a termination signal, and the time when the processes are forcibly halted with a kill signal. Set this value to longer than the expected cleanup time for your process. Value must be a non-negative integer. A zero value indicates delete immediately. You might need to increase the grace period for very large Kafka clusters, so that the Kafka brokers have enough time to transfer their work to another broker before they are terminated. Defaults to 30 seconds.
|affinity
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core[Affinity]
|The pod's affinity rules.
|tolerations
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core[Toleration] array
|The pod's tolerations.
|topologySpreadConstraints
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#topologyspreadconstraint-v1-core[TopologySpreadConstraint] array
|The pod's topology spread constraints.
|priorityClassName
|string
|The name of the priority class used to assign priority to the pods. 
|schedulerName
|string
|The name of the scheduler used to dispatch this `Pod`. If not specified, the default scheduler will be used.
|hostAliases
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#hostalias-v1-core[HostAlias] array
|The pod's HostAliases. HostAliases is an optional list of hosts and IPs that will be injected into the Pod's hosts file if specified.
|dnsPolicy
|string (one of [ClusterFirstWithHostNet, ClusterFirst, Default, None])
|The pod's DNSPolicy. Defaults to `ClusterFirst`. Valid values are `ClusterFirstWithHostNet`, `ClusterFirst`, `Default` or `None`.
|dnsConfig
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#poddnsconfig-v1-core[PodDNSConfig]
|The pod's DNSConfig. If specified, it will be merged to the generated DNS configuration based on the DNSPolicy.
|enableServiceLinks
|boolean
|Indicates whether information about services should be injected into Pod's environment variables.
|tmpDirSizeLimit
|string
|Defines the total amount of pod memory allocated for the temporary `EmptyDir` volume `/tmp`. Specify the allocation in memory units, for example, `100Mi` for 100 mebibytes. Default value is `5Mi`. The `/tmp` volume is backed by pod memory, not disk storage, so avoid setting a high value as it consumes pod memory resources.
|volumes
|xref:type-AdditionalVolume-{context}[`AdditionalVolume`] array
|Additional volumes that can be mounted to the pod.
|templatedVolumes
|xref:type-AdditionalTemplatedVolume-{context}[`AdditionalTemplatedVolume`] array
|Additional volumes that can be mounted to the pod. These volumes can use templates to mount different volumes into individual Pods.
|hostUsers
|boolean
|Use the host user namespace. Optional. Defaults to `true`. When `true` or not set, the pod runs in the host user namespace. This is required when the pod needs features available only in the host namespace, such as loading kernel modules with `CAP_SYS_MODULE`.When set to `false`, the pod runs in a new user namespace. Setting `false` helps mitigate container breakout vulnerabilities and allows containers to run as `root` without granting `root` privileges on the host. This property is alpha-level in Kubernetes and is supported only by Kubernetes clusters that enable the `UserNamespacesSupport` feature.
|====

[id='type-MetadataTemplate-{context}']
= `MetadataTemplate` schema reference

Used in: xref:type-BuildConfigTemplate-{context}[`BuildConfigTemplate`], xref:type-DeploymentTemplate-{context}[`DeploymentTemplate`], xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`], xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`], xref:type-PodTemplate-{context}[`PodTemplate`], xref:type-ResourceTemplate-{context}[`ResourceTemplate`], xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]

xref:type-MetadataTemplate-schema-{context}[Full list of `MetadataTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.MetadataTemplate.adoc[leveloffset=+1]

[id='type-MetadataTemplate-schema-{context}']
== `MetadataTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|labels
|map
|Labels added to the Kubernetes resource.
|annotations
|map
|Annotations added to the Kubernetes resource.
|====

[id='type-AdditionalVolume-{context}']
= `AdditionalVolume` schema reference

Used in: xref:type-PodTemplate-{context}[`PodTemplate`], xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|Name to use for the volume. Required.
|secret
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#secretvolumesource-v1-core[SecretVolumeSource]
|`Secret` to use to populate the volume.
|configMap
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#configmapvolumesource-v1-core[ConfigMapVolumeSource]
|`ConfigMap` to use to populate the volume.
|emptyDir
|xref:type-EmptyDirVolume-{context}[`EmptyDirVolume`]
|`EmptyDir` to use to populate the volume.
|persistentVolumeClaim
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#persistentvolumeclaimvolumesource-v1-core[PersistentVolumeClaimVolumeSource]
|`PersistentVolumeClaim` object to use to populate the volume.
|csi
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#csivolumesource-v1-core[CSIVolumeSource]
|`CSIVolumeSource` object to use to populate the volume.
|image
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#imagevolumesource-v1-core[ImageVolumeSource]
|`ImageVolumeSource` object to use to populate the volume.
|projected
|xref:type-ProjectedVolume-{context}[`ProjectedVolume`]
|`ProjectedVolume` object to use volume projection.
|====

[id='type-EmptyDirVolume-{context}']
= `EmptyDirVolume` schema reference

Used in: xref:type-AdditionalVolume-{context}[`AdditionalVolume`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|medium
|string (one of [Memory])
|Medium represents the type of storage medium should back this volume. Valid values are unset or `Memory`. When not set, it will use the node's default medium.
|sizeLimit
|string
|The total amount of local storage required for this EmptyDir volume (for example 1Gi).
|====

[id='type-ProjectedVolume-{context}']
= `ProjectedVolume` schema reference

Used in: xref:type-AdditionalVolume-{context}[`AdditionalVolume`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|sources
|xref:type-ProjectedVolumeSource-{context}[`ProjectedVolumeSource`] array
|List of projections that are part of this projected volumes. Currently, only Service Account projection is supported.
|====

[id='type-ProjectedVolumeSource-{context}']
= `ProjectedVolumeSource` schema reference

Used in: xref:type-ProjectedVolume-{context}[`ProjectedVolume`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|serviceAccountToken
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#serviceaccounttokenprojection-v1-core[ServiceAccountTokenProjection]
|Information about the serviceAccountToken data to project.
|====

[id='type-AdditionalTemplatedVolume-{context}']
= `AdditionalTemplatedVolume` schema reference

Used in: xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|Name to use for the volume. Required.
|secret
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#secretvolumesource-v1-core[SecretVolumeSource]
|`Secret` to use to populate the volume. The name of the Secret and the items key and path fields can use placeholders that would be replaced for every individual node. Valid placeholders that you can use in the template are `{nodeId}` and `{nodePodName}`.
|configMap
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#configmapvolumesource-v1-core[ConfigMapVolumeSource]
|`ConfigMap` to use to populate the volume. The name of the ConfigMap and the items key and path fields can use placeholders that would be replaced for every individual node. Valid placeholders that you can use in the template are `{nodeId}` and `{nodePodName}`.
|persistentVolumeClaim
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#persistentvolumeclaimvolumesource-v1-core[PersistentVolumeClaimVolumeSource]
|`PersistentVolumeClaim` object to use to populate the volume. The name of the Persistent Volume Claim can use placeholders that would be replaced for every individual node. Valid placeholders that you can use in the template are `{nodeId}` and `{nodePodName}`.
|====

[id='type-InternalServiceTemplate-{context}']
= `InternalServiceTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata applied to the resource.
|ipFamilyPolicy
|string (one of [RequireDualStack, SingleStack, PreferDualStack])
|Specifies the IP Family Policy used by the service. Available options are `SingleStack`, `PreferDualStack` and `RequireDualStack`. `SingleStack` is for a single IP family. `PreferDualStack` is for two IP families on dual-stack configured clusters or a single IP family on single-stack clusters. `RequireDualStack` fails unless there are two IP families on dual-stack configured clusters. If unspecified, Kubernetes will choose the default value based on the service type.
|ipFamilies
|string (one or more of [IPv6, IPv4]) array
|Specifies the IP Families used by the service. Available options are `IPv4` and `IPv6`. If unspecified, Kubernetes will choose the default value based on the `ipFamilyPolicy` setting.
|====

[id='type-ResourceTemplate-{context}']
= `ResourceTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`], xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`], xref:type-KafkaNodePoolTemplate-{context}[`KafkaNodePoolTemplate`], xref:type-KafkaUserTemplate-{context}[`KafkaUserTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata applied to the resource.
|====

[id='type-PodDisruptionBudgetTemplate-{context}']
= `PodDisruptionBudgetTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`], xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`]

xref:type-PodDisruptionBudgetTemplate-schema-{context}[Full list of `PodDisruptionBudgetTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.PodDisruptionBudgetTemplate.adoc[leveloffset=+1]

[id='type-PodDisruptionBudgetTemplate-schema-{context}']
== `PodDisruptionBudgetTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata to apply to the `PodDisruptionBudgetTemplate` resource.
|maxUnavailable
|integer
|Maximum number of unavailable pods to allow automatic Pod eviction. A Pod eviction is allowed when the `maxUnavailable` number of pods or fewer are unavailable after the eviction. Setting this value to 0 prevents all voluntary evictions, so the pods must be evicted manually. Defaults to 1.
|====

[id='type-ContainerTemplate-{context}']
= `ContainerTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaClusterTemplate-{context}[`KafkaClusterTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`], xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`], xref:type-KafkaNodePoolTemplate-{context}[`KafkaNodePoolTemplate`]

xref:type-ContainerTemplate-schema-{context}[Full list of `ContainerTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.ContainerTemplate.adoc[leveloffset=+1]

[id='type-ContainerTemplate-schema-{context}']
== `ContainerTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|env
|xref:type-ContainerEnvVar-{context}[`ContainerEnvVar`] array
|Environment variables which should be applied to the container.
|securityContext
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#securitycontext-v1-core[SecurityContext]
|Security context for the container.
|volumeMounts
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#volumemount-v1-core[VolumeMount] array
|Additional volume mounts which should be applied to the container.
|====

[id='type-ContainerEnvVar-{context}']
= `ContainerEnvVar` schema reference

Used in: xref:type-ContainerTemplate-{context}[`ContainerTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The environment variable key.
|value
|string
|The environment variable value.
|valueFrom
|xref:type-ContainerEnvVarSource-{context}[`ContainerEnvVarSource`]
|Reference to the secret or config map property to which the environment variable is set.
|====

[id='type-ContainerEnvVarSource-{context}']
= `ContainerEnvVarSource` schema reference

Used in: xref:type-ContainerEnvVar-{context}[`ContainerEnvVar`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretKeyRef
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#secretkeyselector-v1-core[SecretKeySelector]
|Reference to a key in a secret.
|configMapKeyRef
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#configmapkeyselector-v1-core[ConfigMapKeySelector]
|Reference to a key in a config map.
|====

[id='type-TieredStorageCustom-{context}']
= `TieredStorageCustom` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]

xref:type-TieredStorageCustom-schema-{context}[Full list of `TieredStorageCustom` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.tieredstorage.TieredStorageCustom.adoc[leveloffset=+1]

[id='type-TieredStorageCustom-schema-{context}']
== `TieredStorageCustom` schema properties


The `type` property is a discriminator that distinguishes use of the `TieredStorageCustom` type from other subtypes that may be added in the future.
It must have the value `custom` for the type `TieredStorageCustom`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `custom`.
|remoteStorageManager
|xref:type-RemoteStorageManager-{context}[`RemoteStorageManager`]
|Configuration for the Remote Storage Manager.
|====

[id='type-RemoteStorageManager-{context}']
= `RemoteStorageManager` schema reference

Used in: xref:type-TieredStorageCustom-{context}[`TieredStorageCustom`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|className
|string
|The class name for the `RemoteStorageManager` implementation.
|classPath
|string
|The class path for the `RemoteStorageManager` implementation.
|config
|map
|The additional configuration map for the `RemoteStorageManager` implementation. Keys will be automatically prefixed with `rsm.config.`, and added to Kafka broker configuration.
|====

[id='type-QuotasPluginKafka-{context}']
= `QuotasPluginKafka` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]


The `type` property is a discriminator that distinguishes use of the `QuotasPluginKafka` type from xref:type-QuotasPluginStrimzi-{context}[`QuotasPluginStrimzi`].
It must have the value `kafka` for the type `QuotasPluginKafka`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `kafka`.
|producerByteRate
|integer
|The default client quota on the maximum bytes per-second that each client can publish to each broker before it is throttled. Applied on a per-broker basis.
|consumerByteRate
|integer
|The default client quota on the maximum bytes per-second that each client can fetch from each broker before it is throttled. Applied on a per-broker basis.
|requestPercentage
|integer
|The default client quota limits the maximum CPU utilization of each client as a percentage of the network and I/O threads of each broker. Applied on a per-broker basis.
|controllerMutationRate
|number
|The default client quota on the rate at which mutations are accepted per second for create topic requests, create partition requests, and delete topic requests, defined for each broker. The mutations rate is measured by the number of partitions created or deleted. Applied on a per-broker basis.
|====

[id='type-QuotasPluginStrimzi-{context}']
= `QuotasPluginStrimzi` schema reference

Used in: xref:type-KafkaClusterSpec-{context}[`KafkaClusterSpec`]


The `type` property is a discriminator that distinguishes use of the `QuotasPluginStrimzi` type from xref:type-QuotasPluginKafka-{context}[`QuotasPluginKafka`].
It must have the value `strimzi` for the type `QuotasPluginStrimzi`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `strimzi`.
|producerByteRate
|integer
|A per-broker byte-rate quota for clients producing to a broker, independent of their number. If clients produce at maximum speed, the quota is shared equally between all non-excluded producers. Otherwise, the quota is divided based on each client's production rate.
|consumerByteRate
|integer
|A per-broker byte-rate quota for clients consuming from a broker, independent of their number. If clients consume at maximum speed, the quota is shared equally between all non-excluded consumers. Otherwise, the quota is divided based on each client's consumption rate.
|minAvailableBytesPerVolume
|integer
|Stop message production if the available size (in bytes) of the storage is lower than or equal to this specified value. This condition is mutually exclusive with `minAvailableRatioPerVolume`.
|minAvailableRatioPerVolume
|number
|Stop message production if the percentage of available storage space falls below or equals the specified ratio (set as a decimal representing a percentage). This condition is mutually exclusive with `minAvailableBytesPerVolume`.
|excludedPrincipals
|string array
|List of principals that are excluded from the quota. The principals have to be prefixed with `User:`, for example `User:my-user;User:CN=my-other-user`.
|====

[id='type-EntityOperatorSpec-{context}']
= `EntityOperatorSpec` schema reference

Used in: xref:type-KafkaSpec-{context}[`KafkaSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|topicOperator
|xref:type-EntityTopicOperatorSpec-{context}[`EntityTopicOperatorSpec`]
|Configuration of the Topic Operator.
|userOperator
|xref:type-EntityUserOperatorSpec-{context}[`EntityUserOperatorSpec`]
|Configuration of the User Operator.
|template
|xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`]
|Template for Entity Operator resources. The template allows users to specify how a `Deployment` and `Pod` is generated.
|====

[id='type-EntityTopicOperatorSpec-{context}']
= `EntityTopicOperatorSpec` schema reference

Used in: xref:type-EntityOperatorSpec-{context}[`EntityOperatorSpec`]

xref:type-EntityTopicOperatorSpec-schema-{context}[Full list of `EntityTopicOperatorSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityTopicOperatorSpec.adoc[leveloffset=+1]

[id='type-EntityTopicOperatorSpec-schema-{context}']
== `EntityTopicOperatorSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|watchedNamespace
|string
|The namespace the Topic Operator should watch.
|image
|string
|The image to use for the Topic Operator.
|reconciliationIntervalMs
|integer
|Interval between periodic reconciliations in milliseconds.
|startupProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod startup checking.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|====

[id='type-EntityUserOperatorSpec-{context}']
= `EntityUserOperatorSpec` schema reference

Used in: xref:type-EntityOperatorSpec-{context}[`EntityOperatorSpec`]

xref:type-EntityUserOperatorSpec-schema-{context}[Full list of `EntityUserOperatorSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.entityoperator.EntityUserOperatorSpec.adoc[leveloffset=+1]

[id='type-EntityUserOperatorSpec-schema-{context}']
== `EntityUserOperatorSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|watchedNamespace
|string
|The namespace the User Operator should watch.
|image
|string
|The image to use for the User Operator.
|reconciliationIntervalMs
|integer
|Interval between periodic reconciliations in milliseconds.
|secretPrefix
|string
|The prefix that will be added to the KafkaUser name to be used as the Secret name.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|====

[id='type-EntityOperatorTemplate-{context}']
= `EntityOperatorTemplate` schema reference

Used in: xref:type-EntityOperatorSpec-{context}[`EntityOperatorSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|deployment
|xref:type-DeploymentTemplate-{context}[`DeploymentTemplate`]
|Template for Entity Operator `Deployment`.
|pod
|xref:type-PodTemplate-{context}[`PodTemplate`]
|Template for Entity Operator `Pods`.
|topicOperatorContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Entity Topic Operator container.
|userOperatorContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Entity User Operator container.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Entity Operator service account.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for the Entity Operator Pod Disruption Budget.
|entityOperatorRole
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Entity Operator Role.
|topicOperatorRoleBinding
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Entity Topic Operator RoleBinding.
|userOperatorRoleBinding
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Entity Topic Operator RoleBinding.
|====

[id='type-DeploymentTemplate-{context}']
= `DeploymentTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`]

xref:type-DeploymentTemplate-schema-{context}[Full list of `DeploymentTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.DeploymentTemplate.adoc[leveloffset=+1]

[id='type-DeploymentTemplate-schema-{context}']
== `DeploymentTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata applied to the resource.
|deploymentStrategy
|string (one of [RollingUpdate, Recreate])
|Pod replacement strategy for deployment configuration changes. Valid values are `RollingUpdate` and `Recreate`. Defaults to `RollingUpdate`.
|====

[id='type-PodTemplate-{context}']
= `PodTemplate` schema reference

Used in: xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`], xref:type-EntityOperatorTemplate-{context}[`EntityOperatorTemplate`], xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`], xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`], xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`]

xref:type-PodTemplate-schema-{context}[Full list of `PodTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.common.template.PodTemplate.adoc[leveloffset=+1]

[id='type-PodTemplate-schema-{context}']
== `PodTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata applied to the resource.
|imagePullSecrets
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#localobjectreference-v1-core[LocalObjectReference] array
|List of references to secrets in the same namespace to use for pulling any of the images used by this Pod. When the `STRIMZI_IMAGE_PULL_SECRETS` environment variable in Cluster Operator and the `imagePullSecrets` option are specified, only the `imagePullSecrets` variable is used and the `STRIMZI_IMAGE_PULL_SECRETS` variable is ignored.
|securityContext
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#podsecuritycontext-v1-core[PodSecurityContext]
|Configures pod-level security attributes and common container settings.
|terminationGracePeriodSeconds
|integer
|The grace period is the duration in seconds after the processes running in the pod are sent a termination signal, and the time when the processes are forcibly halted with a kill signal. Set this value to longer than the expected cleanup time for your process. Value must be a non-negative integer. A zero value indicates delete immediately. You might need to increase the grace period for very large Kafka clusters, so that the Kafka brokers have enough time to transfer their work to another broker before they are terminated. Defaults to 30 seconds.
|affinity
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#affinity-v1-core[Affinity]
|The pod's affinity rules.
|tolerations
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#toleration-v1-core[Toleration] array
|The pod's tolerations.
|topologySpreadConstraints
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#topologyspreadconstraint-v1-core[TopologySpreadConstraint] array
|The pod's topology spread constraints.
|priorityClassName
|string
|The name of the priority class used to assign priority to the pods. 
|schedulerName
|string
|The name of the scheduler used to dispatch this `Pod`. If not specified, the default scheduler will be used.
|hostAliases
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#hostalias-v1-core[HostAlias] array
|The pod's HostAliases. HostAliases is an optional list of hosts and IPs that will be injected into the Pod's hosts file if specified.
|dnsPolicy
|string (one of [ClusterFirstWithHostNet, ClusterFirst, Default, None])
|The pod's DNSPolicy. Defaults to `ClusterFirst`. Valid values are `ClusterFirstWithHostNet`, `ClusterFirst`, `Default` or `None`.
|dnsConfig
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#poddnsconfig-v1-core[PodDNSConfig]
|The pod's DNSConfig. If specified, it will be merged to the generated DNS configuration based on the DNSPolicy.
|enableServiceLinks
|boolean
|Indicates whether information about services should be injected into Pod's environment variables.
|tmpDirSizeLimit
|string
|Defines the total amount of pod memory allocated for the temporary `EmptyDir` volume `/tmp`. Specify the allocation in memory units, for example, `100Mi` for 100 mebibytes. Default value is `5Mi`. The `/tmp` volume is backed by pod memory, not disk storage, so avoid setting a high value as it consumes pod memory resources.
|volumes
|xref:type-AdditionalVolume-{context}[`AdditionalVolume`] array
|Additional volumes that can be mounted to the pod.
|hostUsers
|boolean
|Use the host user namespace. Optional. Defaults to `true`. When `true` or not set, the pod runs in the host user namespace. This is required when the pod needs features available only in the host namespace, such as loading kernel modules with `CAP_SYS_MODULE`.When set to `false`, the pod runs in a new user namespace. Setting `false` helps mitigate container breakout vulnerabilities and allows containers to run as `root` without granting `root` privileges on the host. This property is alpha-level in Kubernetes and is supported only by Kubernetes clusters that enable the `UserNamespacesSupport` feature.
|====

[id='type-CertificateAuthority-{context}']
= `CertificateAuthority` schema reference

Used in: xref:type-KafkaSpec-{context}[`KafkaSpec`]

Configuration of how TLS certificates are used within the cluster. This applies to certificates used for both internal communication within the cluster and to certificates used for client access via `Kafka.spec.kafka.listeners.tls`.

[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|generateCertificateAuthority
|boolean
|If true then Certificate Authority certificates will be generated automatically. Otherwise the user will need to provide a Secret with the CA certificate. Default is true.
|type
|string (one of [strimzi, cert-manager])
|The type of certificate manager. The available types are `strimzi` and `cert-manager`. Default is `strimzi`.
|generateSecretOwnerReference
|boolean
|If `true`, the Cluster and Client CA Secrets are configured with the `ownerReference` set to the `Kafka` resource. If the `Kafka` resource is deleted when `true`, the CA Secrets are also deleted. If `false`, the `ownerReference` is disabled. If the `Kafka` resource is deleted when `false`, the CA Secrets are retained and available for reuse. Default is `true`.
|validityDays
|integer
|The number of days generated certificates should be valid for. The default is 365.
|renewalDays
|integer
|The number of days in the certificate renewal period. This is the number of days before the a certificate expires during which renewal actions may be performed. When `generateCertificateAuthority` is true, this will cause the generation of a new certificate. When `generateCertificateAuthority` is false, this will cause extra logging at WARN level about the pending certificate expiry. Default is 30.
|keySize
|integer
|The RSA key size in bits for CA and end-entity certificate keys. Must be at least 2048. The default is 4096.
|certificateExpirationPolicy
|string (one of [replace-key, renew-certificate])
|How should CA certificate expiration be handled when `generateCertificateAuthority=true`. The default is for a new CA certificate to be generated reusing the existing private key.
|certManager
|xref:type-CertManager-{context}[`CertManager`]
|Configuration for using cert-manager to issue certificates. This only applies if the CA type is set to `cert-manager`.
|====

[id='type-CertManager-{context}']
= `CertManager` schema reference

Used in: xref:type-CertificateAuthority-{context}[`CertificateAuthority`]

Configuration for using cert-manager to issue certificates. This only applies if the CA type is set to `cert-manager`.

[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|issuerRef
|xref:type-IssuerRef-{context}[`IssuerRef`]
|Reference to the cert-manager issuer to use for issuing certificates. Required.
|caCertRef
|xref:type-CaCertRef-{context}[`CaCertRef`]
|Reference to the Secret containing the CA certificate (public key) that trusts certificates issued by cert-manager. Required.
|====

[id='type-IssuerRef-{context}']
= `IssuerRef` schema reference

Used in: xref:type-CertManager-{context}[`CertManager`]

Reference to the cert-manager issuer for TLS certificates. This only applies if the CA type is set to `cert-manager`.

[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The name of the cert-manager issuer. Required.
|kind
|string (one of [Issuer, ClusterIssuer])
|The kind of the cert-manager issuer. Must be either `Issuer` or `ClusterIssuer`. Required.
|group
|string
|The group of the cert-manager issuer. Default is `cert-manager.io`.
|====

[id='type-CaCertRef-{context}']
= `CaCertRef` schema reference

Used in: xref:type-CertManager-{context}[`CertManager`]

Reference to the Secret containing the CA certificate (public key) that trusts certificates issued by cert-manager. This only applies if the CA type is set to `cert-manager`.

[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretName
|string
|The name of the Secret. Required.
|certificate
|string
|The key under which the CA certificate is stored in the Secret. Required.
|====

[id='type-CruiseControlSpec-{context}']
= `CruiseControlSpec` schema reference

Used in: xref:type-KafkaSpec-{context}[`KafkaSpec`]

xref:type-CruiseControlSpec-schema-{context}[Full list of `CruiseControlSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.kafka.cruisecontrol.CruiseControlSpec.adoc[leveloffset=+1]

[id='type-CruiseControlSpec-schema-{context}']
== `CruiseControlSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|image
|string
|The container image used for Cruise Control pods. If no image name is explicitly specified, the image name corresponds to the name specified in the Cluster Operator configuration. If an image name is not defined in the Cluster Operator configuration, a default value is used.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve for the Cruise Control container.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking for the Cruise Control container.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking for the Cruise Control container.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for the Cruise Control container.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration (Log4j 2) for Cruise Control.
|template
|xref:type-CruiseControlTemplate-{context}[`CruiseControlTemplate`]
|Template to specify how Cruise Control resources, `Deployments` and `Pods`, are generated.
|brokerCapacity
|xref:type-BrokerCapacity-{context}[`BrokerCapacity`]
|The Cruise Control `brokerCapacity` configuration.
|config
|map
|The Cruise Control configuration. For a full list of configuration options refer to https://github.com/linkedin/cruise-control/wiki/Configurations. Note that properties with the following prefixes cannot be set: bootstrap.servers, client.id, zookeeper., network., security., failed.brokers.zk.path,webserver.http., webserver.ssl., webserver.api.urlprefix, webserver.session.path, webserver.accesslog., two.step., request.reason.required,metric.reporter.sampler.bootstrap.servers, capacity.config.file, self.healing., ssl., kafka.broker.failure.detection.enable, topic.config.provider.class (with the exception of: ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, webserver.http.cors.enabled, webserver.http.cors.origin, webserver.http.cors.exposeheaders, webserver.security.enable).
|metricsConfig
|xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`], xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]
|Metrics configuration. Only `jmxPrometheusExporter` can be configured, as this component does not support `strimziMetricsReporter`.
|apiUsers
|xref:type-HashLoginServiceApiUsers-{context}[`HashLoginServiceApiUsers`]
|Configuration of the Cruise Control REST API users.
|autoRebalance
|xref:type-KafkaAutoRebalanceConfiguration-{context}[`KafkaAutoRebalanceConfiguration`] array
|Auto-rebalancing on scaling related configuration listing the modes, when brokers are added or removed, with the corresponding rebalance template configurations.If this field is set, at least one mode has to be defined.
|====

[id='type-CruiseControlTemplate-{context}']
= `CruiseControlTemplate` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|deployment
|xref:type-DeploymentTemplate-{context}[`DeploymentTemplate`]
|Template for Cruise Control `Deployment`.
|pod
|xref:type-PodTemplate-{context}[`PodTemplate`]
|Template for Cruise Control `Pods`.
|apiService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for Cruise Control API `Service`.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for Cruise Control `PodDisruptionBudget`.
|cruiseControlContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Cruise Control container.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Cruise Control service account.
|====

[id='type-BrokerCapacity-{context}']
= `BrokerCapacity` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|cpu
|string
|Broker capacity for CPU resource in cores or millicores. For example, 1, 1.500, 1500m. For more information on valid CPU resource units see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu.
|inboundNetwork
|string
|Broker capacity for inbound network throughput in bytes per second. Use an integer value with standard Kubernetes byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s.
|outboundNetwork
|string
|Broker capacity for outbound network throughput in bytes per second. Use an integer value with standard Kubernetes byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s.
|overrides
|xref:type-BrokerCapacityOverride-{context}[`BrokerCapacityOverride`] array
|Overrides for individual brokers. The `overrides` property lets you specify a different capacity configuration for different brokers.
|====

[id='type-BrokerCapacityOverride-{context}']
= `BrokerCapacityOverride` schema reference

Used in: xref:type-BrokerCapacity-{context}[`BrokerCapacity`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|brokers
|integer array
|List of Kafka brokers (broker identifiers).
|cpu
|string
|Broker capacity for CPU resource in cores or millicores. For example, 1, 1.500, 1500m. For more information on valid CPU resource units see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu.
|inboundNetwork
|string
|Broker capacity for inbound network throughput in bytes per second. Use an integer value with standard Kubernetes byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s.
|outboundNetwork
|string
|Broker capacity for outbound network throughput in bytes per second. Use an integer value with standard Kubernetes byte units (K, M, G) or their bibyte (power of two) equivalents (Ki, Mi, Gi) per second. For example, 10000KiB/s.
|====

[id='type-HashLoginServiceApiUsers-{context}']
= `HashLoginServiceApiUsers` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`]


The `type` property is a discriminator that distinguishes use of the `HashLoginServiceApiUsers` type from other subtypes that may be added in the future.
It must have the value `hashLoginService` for the type `HashLoginServiceApiUsers`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `hashLoginService`.
|valueFrom
|xref:type-PasswordSource-{context}[`PasswordSource`]
|Secret from which the custom Cruise Control API authentication credentials are read.
|====

[id='type-PasswordSource-{context}']
= `PasswordSource` schema reference

Used in: xref:type-HashLoginServiceApiUsers-{context}[`HashLoginServiceApiUsers`], xref:type-Password-{context}[`Password`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretKeyRef
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#secretkeyselector-v1-core[SecretKeySelector]
|Selects a key of a Secret in the resource's namespace.
|====

[id='type-KafkaAutoRebalanceConfiguration-{context}']
= `KafkaAutoRebalanceConfiguration` schema reference

Used in: xref:type-CruiseControlSpec-{context}[`CruiseControlSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|mode
|string (one of [remove-brokers, add-brokers])
|Specifies the mode for automatically rebalancing when brokers are added or removed. Supported modes are `add-brokers` and `remove-brokers`. 

|template
|xref:type-LocalObjectReference-{context}[`LocalObjectReference`]
|Reference to the KafkaRebalance custom resource to be used as the configuration template for the auto-rebalancing on scaling when running for the corresponding mode.
|====

[id='type-LocalObjectReference-{context}']
= `LocalObjectReference` schema reference

Used in: xref:type-AlterOffsets-{context}[`AlterOffsets`], xref:type-KafkaAutoRebalanceConfiguration-{context}[`KafkaAutoRebalanceConfiguration`], xref:type-ListOffsets-{context}[`ListOffsets`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|
|====

[id='type-KafkaExporterSpec-{context}']
= `KafkaExporterSpec` schema reference

Used in: xref:type-KafkaSpec-{context}[`KafkaSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|image
|string
|The container image used for the Kafka Exporter pods. If no image name is explicitly specified, the image name corresponds to the version specified in the Cluster Operator configuration. If an image name is not defined in the Cluster Operator configuration, a default value is used.
|groupRegex
|string
|Regular expression to specify which consumer groups to collect. Default value is `.*`.
|topicRegex
|string
|Regular expression to specify which topics to collect. Default value is `.*`.
|groupExcludeRegex
|string
|Regular expression to specify which consumer groups to exclude.
|topicExcludeRegex
|string
|Regular expression to specify which topics to exclude.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve.
|logging
|string
|Only log messages with the given severity or above. Valid levels: [`info`, `debug`, `trace`]. Default log level is `info`.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness check.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness check.
|enableSaramaLogging
|boolean
|Enable Sarama logging, a Go client library used by the Kafka Exporter.
|showAllOffsets
|boolean
|Whether show the offset/lag for all consumer group, otherwise, only show connected consumer groups.
|template
|xref:type-KafkaExporterTemplate-{context}[`KafkaExporterTemplate`]
|Customization of deployment templates and pods.
|====

[id='type-KafkaExporterTemplate-{context}']
= `KafkaExporterTemplate` schema reference

Used in: xref:type-KafkaExporterSpec-{context}[`KafkaExporterSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|deployment
|xref:type-DeploymentTemplate-{context}[`DeploymentTemplate`]
|Template for Kafka Exporter `Deployment`.
|pod
|xref:type-PodTemplate-{context}[`PodTemplate`]
|Template for Kafka Exporter `Pods`.
|container
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka Exporter container.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka Exporter service account.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for the Pod Disruption Budget for Kafka Exporter pods.
|====

[id='type-KafkaStatus-{context}']
= `KafkaStatus` schema reference

Used in: xref:type-Kafka-{context}[`Kafka`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|listeners
|xref:type-ListenerStatus-{context}[`ListenerStatus`] array
|Addresses of the internal and external listeners.
|kafkaNodePools
|xref:type-UsedNodePoolStatus-{context}[`UsedNodePoolStatus`] array
|List of the KafkaNodePools used by this Kafka cluster.
|clusterId
|string
|Kafka cluster Id.
|operatorLastSuccessfulVersion
|string
|The version of the Strimzi Cluster Operator which performed the last successful reconciliation.
|kafkaVersion
|string
|The version of Kafka currently deployed in the cluster.
|kafkaMetadataVersion
|string
|The KRaft metadata.version currently used by the Kafka cluster.
|autoRebalance
|xref:type-KafkaAutoRebalanceStatus-{context}[`KafkaAutoRebalanceStatus`]
|The status of an auto-rebalancing triggered by a cluster scaling request.
|clusterSecurity
|object
|The current security configuration of the Kafka cluster.
|====

[id='type-Condition-{context}']
= `Condition` schema reference

Used in: xref:type-KafkaBridgeStatus-{context}[`KafkaBridgeStatus`], xref:type-KafkaConnectorStatus-{context}[`KafkaConnectorStatus`], xref:type-KafkaConnectStatus-{context}[`KafkaConnectStatus`], xref:type-KafkaMirrorMaker2Status-{context}[`KafkaMirrorMaker2Status`], xref:type-KafkaNodePoolStatus-{context}[`KafkaNodePoolStatus`], xref:type-KafkaRebalanceStatus-{context}[`KafkaRebalanceStatus`], xref:type-KafkaStatus-{context}[`KafkaStatus`], xref:type-KafkaTopicStatus-{context}[`KafkaTopicStatus`], xref:type-KafkaUserStatus-{context}[`KafkaUserStatus`], xref:type-StrimziPodSetStatus-{context}[`StrimziPodSetStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|The unique identifier of a condition, used to distinguish between other conditions in the resource.
|status
|string
|The status of the condition, either True, False or Unknown.
|lastTransitionTime
|string
|Last time the condition of a type changed from one status to another. The required format is 'yyyy-MM-ddTHH:mm:ssZ', in the UTC time zone.
|reason
|string
|The reason for the condition's last transition (a single word in CamelCase).
|message
|string
|Human-readable message indicating details about the condition's last transition.
|====

[id='type-ListenerStatus-{context}']
= `ListenerStatus` schema reference

Used in: xref:type-KafkaStatus-{context}[`KafkaStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The name of the listener.
|addresses
|xref:type-ListenerAddress-{context}[`ListenerAddress`] array
|A list of the addresses for this listener.
|bootstrapServers
|string
|A comma-separated list of `host:port` pairs for connecting to the Kafka cluster using this listener.
|certificates
|string array
|A list of TLS certificates which can be used to verify the identity of the server when connecting to the given listener. Set only for `tls` and `external` listeners.
|====

[id='type-ListenerAddress-{context}']
= `ListenerAddress` schema reference

Used in: xref:type-ListenerStatus-{context}[`ListenerStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|host
|string
|The DNS name or IP address of the Kafka bootstrap service.
|port
|integer
|The port of the Kafka bootstrap service.
|====

[id='type-UsedNodePoolStatus-{context}']
= `UsedNodePoolStatus` schema reference

Used in: xref:type-KafkaStatus-{context}[`KafkaStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The name of the KafkaNodePool used by this Kafka resource.
|====

[id='type-KafkaAutoRebalanceStatus-{context}']
= `KafkaAutoRebalanceStatus` schema reference

Used in: xref:type-KafkaStatus-{context}[`KafkaStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|state
|string (one of [RebalanceOnScaleUp, Idle, RebalanceOnScaleDown])
|The current state of an auto-rebalancing operation. Possible values are: 

* `Idle` as the initial state when an auto-rebalancing is requested or as final state when it completes or fails.
* `RebalanceOnScaleDown` if an auto-rebalance related to a scale-down operation is running.
* `RebalanceOnScaleUp` if an auto-rebalance related to a scale-up operation is running.
|lastTransitionTime
|string
|The timestamp of the latest auto-rebalancing state update.
|modes
|xref:type-KafkaAutoRebalanceStatusBrokers-{context}[`KafkaAutoRebalanceStatusBrokers`] array
|List of modes where an auto-rebalancing operation is either running or queued. 
Each mode entry (`add-brokers` or `remove-brokers`) includes one of the following: 

* Broker IDs for a current auto-rebalance. 
* Broker IDs for a queued auto-rebalance (if a previous rebalance is still in progress).
|====

[id='type-KafkaAutoRebalanceStatusBrokers-{context}']
= `KafkaAutoRebalanceStatusBrokers` schema reference

Used in: xref:type-KafkaAutoRebalanceStatus-{context}[`KafkaAutoRebalanceStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|mode
|string (one of [remove-brokers, add-brokers])
|Mode for which there is an auto-rebalancing operation in progress or queued, when brokers are added or removed. The possible modes are `add-brokers` and `remove-brokers`.
|brokers
|integer array
|List of broker IDs involved in an auto-rebalancing operation related to the current mode. 
The list contains one of the following: 

* Broker IDs for a current auto-rebalance. 
* Broker IDs for a queued auto-rebalance (if a previous auto-rebalance is still in progress). 

|====

[id='type-KafkaConnect-{context}']
= `KafkaConnect` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`]
|The specification of the Kafka Connect cluster.
|status
|xref:type-KafkaConnectStatus-{context}[`KafkaConnectStatus`]
|The status of the Kafka Connect cluster.
|====

[id='type-KafkaConnectSpec-{context}']
= `KafkaConnectSpec` schema reference

Used in: xref:type-KafkaConnect-{context}[`KafkaConnect`]

xref:type-KafkaConnectSpec-schema-{context}[Full list of `KafkaConnectSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.connect.KafkaConnectSpec.adoc[leveloffset=+1]

[id='type-KafkaConnectSpec-schema-{context}']
== `KafkaConnectSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|version
|string
|The Kafka Connect version. Defaults to the latest version. Consult the user documentation to understand the process required to upgrade or downgrade the version.
|replicas
|integer
|The number of pods in the Kafka Connect group. Required in the `v1` version of the Strimzi API.
|image
|string
|The container image used for Kafka Connect pods. If no image name is explicitly specified, it is determined based on the `spec.version` configuration. The image names are specifically mapped to corresponding versions in the Cluster Operator configuration.
|bootstrapServers
|string
|Bootstrap servers to connect to. This should be given as a comma separated list of _<hostname>_:__ pairs.
|groupId
|string
|A unique ID that identifies the Connect cluster group.
|configStorageTopic
|string
|The name of the Kafka topic where connector configurations are stored.
|statusStorageTopic
|string
|The name of the Kafka topic where connector and task status are stored.
|offsetStorageTopic
|string
|The name of the Kafka topic where source connector offsets are stored.
|tls
|xref:type-ClientTls-{context}[`ClientTls`]
|TLS configuration.
|authentication
|xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`]
|Authentication configuration for Kafka Connect.
|config
|map
|The Kafka Connect configuration. Properties with the following prefixes cannot be set: group.id, config.storage.topic, offset.storage.topic, status.storage.topic, ssl., sasl., security., listeners, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes, prometheus.metrics.reporter. (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, rest.extension.classes).
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|The maximum limits for CPU and memory resources and the requested initial resources.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|jmxOptions
|xref:type-KafkaJmxOptions-{context}[`KafkaJmxOptions`]
|JMX Options.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration for Kafka Connect.
|clientRackInitImage
|string
|The image of the init container used for initializing the `client.rack`.
|rack
|xref:type-TopologyLabelRack-{context}[`TopologyLabelRack`], xref:type-EnvironmentVariableRack-{context}[`EnvironmentVariableRack`]
|Configuration of the node label which will be used as the `client.rack` consumer configuration.
|metricsConfig
|xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`], xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]
|Metrics configuration.
|tracing
|xref:type-OpenTelemetryTracing-{context}[`OpenTelemetryTracing`]
|The configuration of tracing in Kafka Connect.
|template
|xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`]
|Template for Kafka Connect and Kafka MirrorMaker 2 resources. The template allows users to specify how the `Pods`, `Service`, and other services are generated.
|build
|xref:type-Build-{context}[`Build`]
|Configures how the Connect container image should be built. Optional.
|plugins
|xref:type-MountedPlugin-{context}[`MountedPlugin`] array
|List of connector plugins to mount into the `KafkaConnect` pod.
|====

[id='type-ClientTls-{context}']
= `ClientTls` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-ClientTls-schema-{context}[Full list of `ClientTls` schema properties]

include::../api/io.strimzi.api.kafka.model.common.ClientTls.adoc[leveloffset=+1]

[id='type-ClientTls-schema-{context}']
== `ClientTls` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|trustedCertificates
|xref:type-CertSecretSource-{context}[`CertSecretSource`] array
|Trusted certificates for TLS connection.
|====

[id='type-CertSecretSource-{context}']
= `CertSecretSource` schema reference

Used in: xref:type-ClientTls-{context}[`ClientTls`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretName
|string
|The name of the Secret containing the certificate.
|certificate
|string
|The name of the file certificate in the secret.
|pattern
|string
|Pattern for the certificate files in the secret. Use the link:https://en.wikipedia.org/wiki/Glob_(programming)[_glob syntax_] for the pattern. All files in the secret that match the pattern are used.
|====

[id='type-KafkaClientAuthenticationTls-{context}']
= `KafkaClientAuthenticationTls` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-KafkaClientAuthenticationTls-schema-{context}[Full list of `KafkaClientAuthenticationTls` schema properties]

include::../api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationTls.adoc[leveloffset=+1]

[id='type-KafkaClientAuthenticationTls-schema-{context}']
== `KafkaClientAuthenticationTls` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaClientAuthenticationTls` type from xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`].
It must have the value `tls` for the type `KafkaClientAuthenticationTls`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `tls`.
|certificateAndKey
|xref:type-CertAndKeySecretSource-{context}[`CertAndKeySecretSource`]
|Reference to the `Secret` which holds the certificate and private key pair.
|====

[id='type-KafkaClientAuthenticationScramSha256-{context}']
= `KafkaClientAuthenticationScramSha256` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-KafkaClientAuthenticationScramSha256-schema-{context}[Full list of `KafkaClientAuthenticationScramSha256` schema properties]

include::../api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationScramSha256.adoc[leveloffset=+1]

[id='type-KafkaClientAuthenticationScramSha256-schema-{context}']
== `KafkaClientAuthenticationScramSha256` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `scram-sha-256`.
|username
|string
|Username used for the authentication.
|passwordSecret
|xref:type-PasswordSecretSource-{context}[`PasswordSecretSource`]
|Reference to the `Secret` which holds the password.
|====

[id='type-PasswordSecretSource-{context}']
= `PasswordSecretSource` schema reference

Used in: xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secretName
|string
|The name of the Secret containing the password.
|password
|string
|The name of the key in the Secret under which the password is stored.
|====

[id='type-KafkaClientAuthenticationScramSha512-{context}']
= `KafkaClientAuthenticationScramSha512` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-KafkaClientAuthenticationScramSha512-schema-{context}[Full list of `KafkaClientAuthenticationScramSha512` schema properties]

include::../api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationScramSha512.adoc[leveloffset=+1]

[id='type-KafkaClientAuthenticationScramSha512-schema-{context}']
== `KafkaClientAuthenticationScramSha512` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `scram-sha-512`.
|username
|string
|Username used for the authentication.
|passwordSecret
|xref:type-PasswordSecretSource-{context}[`PasswordSecretSource`]
|Reference to the `Secret` which holds the password.
|====

[id='type-KafkaClientAuthenticationPlain-{context}']
= `KafkaClientAuthenticationPlain` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-KafkaClientAuthenticationPlain-schema-{context}[Full list of `KafkaClientAuthenticationPlain` schema properties]

include::../api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationPlain.adoc[leveloffset=+1]

[id='type-KafkaClientAuthenticationPlain-schema-{context}']
== `KafkaClientAuthenticationPlain` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaClientAuthenticationPlain` type from xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`].
It must have the value `plain` for the type `KafkaClientAuthenticationPlain`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `plain`.
|username
|string
|Username used for the authentication.
|passwordSecret
|xref:type-PasswordSecretSource-{context}[`PasswordSecretSource`]
|Reference to the `Secret` which holds the password.
|====

[id='type-KafkaClientAuthenticationCustom-{context}']
= `KafkaClientAuthenticationCustom` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`], xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]

xref:type-KafkaClientAuthenticationCustom-schema-{context}[Full list of `KafkaClientAuthenticationCustom` schema properties]

include::../api/io.strimzi.api.kafka.model.common.authentication.KafkaClientAuthenticationCustom.adoc[leveloffset=+1]

[id='type-KafkaClientAuthenticationCustom-schema-{context}']
== `KafkaClientAuthenticationCustom` schema properties


The `type` property is a discriminator that distinguishes use of the `KafkaClientAuthenticationCustom` type from xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`].
It must have the value `custom` for the type `KafkaClientAuthenticationCustom`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `custom`.
|sasl
|boolean
|Enable or disable SASL on this authentication mechanism.
|config
|map
|Configuration for the custom authentication mechanism. Only properties with the `sasl.` and `ssl.keystore.` prefixes are allowed. Specify other options in the regular configuration section of the custom resource.
|====

[id='type-OpenTelemetryTracing-{context}']
= `OpenTelemetryTracing` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`], xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


The `type` property is a discriminator that distinguishes use of the `OpenTelemetryTracing` type from other subtypes that may be added in the future.
It must have the value `opentelemetry` for the type `OpenTelemetryTracing`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `opentelemetry`.
|====

[id='type-KafkaConnectTemplate-{context}']
= `KafkaConnectTemplate` schema reference

Used in: xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`], xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|podSet
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka Connect `StrimziPodSet` resource.
|pod
|xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]
|Template for Kafka Connect `Pods`.
|apiService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for Kafka Connect API `Service`.
|headlessService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for Kafka Connect headless `Service`.
|connectContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka Connect container.
|initContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka init container.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for Kafka Connect `PodDisruptionBudget`.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka Connect service account.
|clusterRoleBinding
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka Connect ClusterRoleBinding.
|buildPod
|xref:type-PodTemplate-{context}[`PodTemplate`]
|Template for Kafka Connect Build `Pods`. The build pod is used only on Kubernetes.
|buildContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka Connect Build container. The build container is used only on Kubernetes.
|buildConfig
|xref:type-BuildConfigTemplate-{context}[`BuildConfigTemplate`]
|Template for the Kafka Connect BuildConfig used to build new container images. The BuildConfig is used only on OpenShift.
|buildServiceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the Kafka Connect Build service account.
|jmxSecret
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Secret of the Kafka Connect Cluster JMX authentication.
|====

[id='type-BuildConfigTemplate-{context}']
= `BuildConfigTemplate` schema reference

Used in: xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|metadata
|xref:type-MetadataTemplate-{context}[`MetadataTemplate`]
|Metadata to apply to the `PodDisruptionBudgetTemplate` resource.
|pullSecret
|string
|Container Registry Secret with the credentials for pulling the base image.
|====

[id='type-Build-{context}']
= `Build` schema reference

Used in: xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`]

xref:type-Build-schema-{context}[Full list of `Build` schema properties]

include::../api/io.strimzi.api.kafka.model.connect.build.Build.adoc[leveloffset=+1]

[id='type-Build-schema-{context}']
== `Build` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|output
|xref:type-DockerOutput-{context}[`DockerOutput`], xref:type-ImageStreamOutput-{context}[`ImageStreamOutput`]
|Configures where should the newly built image be stored. Required.
|plugins
|xref:type-Plugin-{context}[`Plugin`] array
|List of connector plugins which should be added to the Kafka Connect. Required.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve for the build.
|====

[id='type-DockerOutput-{context}']
= `DockerOutput` schema reference

Used in: xref:type-Build-{context}[`Build`]


The `type` property is a discriminator that distinguishes use of the `DockerOutput` type from xref:type-ImageStreamOutput-{context}[`ImageStreamOutput`].
It must have the value `docker` for the type `DockerOutput`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|image
|string
|The full name which should be used for tagging and pushing the newly built image. For example `quay.io/my-organization/my-custom-connect:latest`. Required.
|pushSecret
|string
|Container Registry Secret with the credentials for pushing the newly built image.
|additionalBuildOptions
|string array
|Configures additional options to pass to the `build` command of Buildah when building a new Kafka Connect image. Allowed Buildah `build` options: --authfile, --cert-dir, --creds, --decryption-key, --retry, --retry-delay, --tls-verify. Those options are used only on Kubernetes, where Buildah is available. They are ignored on OpenShift. For more information, see the link:https://github.com/containers/buildah/blob/main/docs/buildah-build.1.md[Buildah build document^]. Changing this field does not trigger a rebuild of the Kafka Connect image.
|additionalPushOptions
|string array
|Configures additional options to pass to the Buildah `push` command when pushing a new Connect image. Allowed options: --authfile, --cert-dir, --creds, --quiet, --retry, --retry-delay, --tls-verify. Those options are used only on Kubernetes, where Buildah is available. They are ignored on OpenShift. For more information, see the link:https://github.com/containers/buildah/blob/main/docs/buildah-push.1.md[Buildah push document^]. Changing this field does not trigger a rebuild of the Kafka Connect image.
|type
|string
|Must be `docker`.
|====

[id='type-ImageStreamOutput-{context}']
= `ImageStreamOutput` schema reference

Used in: xref:type-Build-{context}[`Build`]


The `type` property is a discriminator that distinguishes use of the `ImageStreamOutput` type from xref:type-DockerOutput-{context}[`DockerOutput`].
It must have the value `imagestream` for the type `ImageStreamOutput`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `imagestream`.
|image
|string
|The name and tag of the ImageStream where the newly built image will be pushed. For example `my-custom-connect:latest`. Required.
|====

[id='type-Plugin-{context}']
= `Plugin` schema reference

Used in: xref:type-Build-{context}[`Build`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|The unique name of the connector plugin. Will be used to generate the path where the connector artifacts will be stored. The name has to be unique within the KafkaConnect resource. The name has to follow the following pattern: `^[a-z][-_a-z0-9]*[a-z]$`. Required.
|artifacts
|xref:type-JarArtifact-{context}[`JarArtifact`], xref:type-TgzArtifact-{context}[`TgzArtifact`], xref:type-ZipArtifact-{context}[`ZipArtifact`], xref:type-MavenArtifact-{context}[`MavenArtifact`], xref:type-OtherArtifact-{context}[`OtherArtifact`] array
|List of artifacts which belong to this connector plugin. Required.
|====

[id='type-JarArtifact-{context}']
= `JarArtifact` schema reference

Used in: xref:type-Plugin-{context}[`Plugin`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `jar`.
|url
|string
|URL of the artifact which will be downloaded. Strimzi does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for `jar`, `zip`, `tgz` and `other` artifacts. Not applicable to the `maven` artifact type.
|sha512sum
|string
|SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the `maven` artifact type. 
|insecure
|boolean
|By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to `true`, all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.
|====

[id='type-TgzArtifact-{context}']
= `TgzArtifact` schema reference

Used in: xref:type-Plugin-{context}[`Plugin`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `tgz`.
|url
|string
|URL of the artifact which will be downloaded. Strimzi does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for `jar`, `zip`, `tgz` and `other` artifacts. Not applicable to the `maven` artifact type.
|sha512sum
|string
|SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the `maven` artifact type. 
|insecure
|boolean
|By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to `true`, all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.
|====

[id='type-ZipArtifact-{context}']
= `ZipArtifact` schema reference

Used in: xref:type-Plugin-{context}[`Plugin`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `zip`.
|url
|string
|URL of the artifact which will be downloaded. Strimzi does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for `jar`, `zip`, `tgz` and `other` artifacts. Not applicable to the `maven` artifact type.
|sha512sum
|string
|SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the `maven` artifact type. 
|insecure
|boolean
|By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to `true`, all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.
|====

[id='type-MavenArtifact-{context}']
= `MavenArtifact` schema reference

Used in: xref:type-Plugin-{context}[`Plugin`]


The `type` property is a discriminator that distinguishes use of the `MavenArtifact` type from xref:type-JarArtifact-{context}[`JarArtifact`], xref:type-TgzArtifact-{context}[`TgzArtifact`], xref:type-ZipArtifact-{context}[`ZipArtifact`], xref:type-OtherArtifact-{context}[`OtherArtifact`].
It must have the value `maven` for the type `MavenArtifact`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `maven`.
|repository
|string
|Maven repository to download the artifact from. Applicable to the `maven` artifact type only.
|mirrors
|xref:type-MavenMirror-{context}[`MavenMirror`] array
|List of Maven mirrors used to download the artifact and its dependencies. All repository requests during the build, including plugin repositories and Maven Central, are redirected to the configured mirror(s). Applicable to the `maven` artifact type only.
|group
|string
|Maven group id. Applicable to the `maven` artifact type only.
|artifact
|string
|Maven artifact id. Applicable to the `maven` artifact type only.
|version
|string
|Maven version number. Applicable to the `maven` artifact type only.
|insecure
|boolean
|By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to `true`, all TLS verification is disabled and the artifacts will be downloaded, even when the server is considered insecure.
|includeScope
|string (one of [system, compile, test, provided, runtime])
|Maven scope for including dependencies for the artifact. Valid values are `compile`, `provided`, `runtime`, `test`, and `system`. When not configured, no scope is set, and all dependencies are included. Applicable to the `maven` artifact type only.
|====

[id='type-MavenMirror-{context}']
= `MavenMirror` schema reference

Used in: xref:type-MavenArtifact-{context}[`MavenArtifact`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|url
|string
|The URL of the Maven mirror. All repository requests during the build, including plugin repositories and Maven Central, are redirected to this mirror. Applicable to the `maven` artifact type only.
|====

[id='type-OtherArtifact-{context}']
= `OtherArtifact` schema reference

Used in: xref:type-Plugin-{context}[`Plugin`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `other`.
|url
|string
|URL of the artifact which will be downloaded. Strimzi does not do any security scanning of the downloaded artifacts. For security reasons, you should first verify the artifacts manually and configure the checksum verification to make sure the same artifact is used in the automated build. Required for `jar`, `zip`, `tgz` and `other` artifacts. Not applicable to the `maven` artifact type.
|sha512sum
|string
|SHA512 checksum of the artifact. Optional. If specified, the checksum will be verified while building the new container. If not specified, the downloaded artifact will not be verified. Not applicable to the `maven` artifact type. 
|fileName
|string
|Name under which the artifact will be stored.
|insecure
|boolean
|By default, connections using TLS are verified to check they are secure. The server certificate used must be valid, trusted, and contain the server name. By setting this option to `true`, all TLS verification is disabled and the artifact will be downloaded, even when the server is considered insecure.
|====

[id='type-MountedPlugin-{context}']
= `MountedPlugin` schema reference

Used in: xref:type-KafkaConnectSpec-{context}[`KafkaConnectSpec`]

xref:type-MountedPlugin-schema-{context}[Full list of `MountedPlugin` schema properties]

include::../api/io.strimzi.api.kafka.model.connect.MountedPlugin.adoc[leveloffset=+1]

[id='type-MountedPlugin-schema-{context}']
== `MountedPlugin` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|name
|string
|A unique name for the connector plugin. This name is used to generate the mount path for the connector artifacts. The name has to be unique within the KafkaConnect resource. The name must be unique within the `KafkaConnect` resource and match the pattern: `^[a-z][-_a-z0-9]*[a-z]$`. Required.
|artifacts
|xref:type-ImageArtifact-{context}[`ImageArtifact`] array
|List of artifacts associated with this connector plugin. Required.
|====

[id='type-ImageArtifact-{context}']
= `ImageArtifact` schema reference

Used in: xref:type-MountedPlugin-{context}[`MountedPlugin`]


The `type` property is a discriminator that distinguishes use of the `ImageArtifact` type from other subtypes that may be added in the future.
It must have the value `image` for the type `ImageArtifact`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `image`.
|reference
|string
|Reference to the container image (OCI artifact) containing the Kafka Connect plugin. The image is mounted as a volume and provides the plugin binary. Required.
|pullPolicy
|string
|Policy that determines when the container image (OCI artifact) is pulled.

Possible values are:

* `Always`: Always pull the image. If the pull fails, container creation fails.
* `Never`: Never pull the image. Use only a locally available image. Container creation fails if the image isn’t present.
* `IfNotPresent`: Pull the image only if it’s not already available locally. Container creation fails if the image isn’t present and the pull fails.

Defaults to `Always` if `:latest` tag is specified, or `IfNotPresent` otherwise.
|====

[id='type-KafkaConnectStatus-{context}']
= `KafkaConnectStatus` schema reference

Used in: xref:type-KafkaConnect-{context}[`KafkaConnect`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|url
|string
|The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors.
|connectorPlugins
|xref:type-ConnectorPlugin-{context}[`ConnectorPlugin`] array
|The list of connector plugins available in this Kafka Connect deployment.
|replicas
|integer
|The current number of pods being used to provide this resource.
|labelSelector
|string
|Label selector for pods providing this resource.
|====

[id='type-ConnectorPlugin-{context}']
= `ConnectorPlugin` schema reference

Used in: xref:type-KafkaConnectStatus-{context}[`KafkaConnectStatus`], xref:type-KafkaMirrorMaker2Status-{context}[`KafkaMirrorMaker2Status`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|class
|string
|The class of the connector plugin.
|type
|string
|The type of the connector plugin. The available types are `sink` and `source`.
|version
|string
|The version of the connector plugin.
|====

[id='type-KafkaTopic-{context}']
= `KafkaTopic` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaTopicSpec-{context}[`KafkaTopicSpec`]
|The specification of the topic.
|status
|xref:type-KafkaTopicStatus-{context}[`KafkaTopicStatus`]
|The status of the topic.
|====

[id='type-KafkaTopicSpec-{context}']
= `KafkaTopicSpec` schema reference

Used in: xref:type-KafkaTopic-{context}[`KafkaTopic`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|topicName
|string
|The name of the topic. When absent this will default to the metadata.name of the topic. It is recommended to not set this unless the topic name is not a valid Kubernetes resource name.
|partitions
|integer
|The number of partitions the topic should have. This cannot be decreased after topic creation. It can be increased after topic creation, but it is important to understand the consequences that has, especially for topics with semantic partitioning. When absent this will default to the broker configuration for `num.partitions`.
|replicas
|integer
|The number of replicas the topic should have. When absent this will default to the broker configuration for `default.replication.factor`.
|config
|map
|The topic configuration.
|====

[id='type-KafkaTopicStatus-{context}']
= `KafkaTopicStatus` schema reference

Used in: xref:type-KafkaTopic-{context}[`KafkaTopic`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|topicName
|string
|Topic name.
|topicId
|string
|The topic's id. For a KafkaTopic with the ready condition, this will change only if the topic gets deleted and recreated with the same name.
|replicasChange
|xref:type-ReplicasChangeStatus-{context}[`ReplicasChangeStatus`]
|Replication factor change status.
|====

[id='type-ReplicasChangeStatus-{context}']
= `ReplicasChangeStatus` schema reference

Used in: xref:type-KafkaTopicStatus-{context}[`KafkaTopicStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|targetReplicas
|integer
|The target replicas value requested by the user. This may be different from .spec.replicas when a change is ongoing.
|state
|string (one of [ongoing, pending])
|Current state of the replicas change operation. This can be `pending`, when the change has been requested, or `ongoing`, when the change has been successfully submitted to Cruise Control.
|message
|string
|Message for the user related to the replicas change request. This may contain transient error messages that would disappear on periodic reconciliations.
|sessionId
|string
|The session identifier for replicas change requests pertaining to this KafkaTopic resource. This is used by the Topic Operator to track the status of `ongoing` replicas change operations.
|====

[id='type-KafkaUser-{context}']
= `KafkaUser` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]
|The specification of the user.
|status
|xref:type-KafkaUserStatus-{context}[`KafkaUserStatus`]
|The status of the Kafka User.
|====

[id='type-KafkaUserSpec-{context}']
= `KafkaUserSpec` schema reference

Used in: xref:type-KafkaUser-{context}[`KafkaUser`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|authentication
|xref:type-KafkaUserTlsClientAuthentication-{context}[`KafkaUserTlsClientAuthentication`], xref:type-KafkaUserTlsExternalClientAuthentication-{context}[`KafkaUserTlsExternalClientAuthentication`], xref:type-KafkaUserScramSha512ClientAuthentication-{context}[`KafkaUserScramSha512ClientAuthentication`]
|Authentication mechanism enabled for this Kafka user. The supported authentication mechanisms are `scram-sha-512`, `tls`, and `tls-external`. 

* `scram-sha-512` generates a secret with SASL SCRAM-SHA-512 credentials.
* `tls` generates a secret with user certificate for mutual TLS authentication.
* `tls-external` does not generate a user certificate.   But prepares the user for using mutual TLS authentication using a user certificate generated outside the User Operator.
  ACLs and quotas set for this user are configured in the `CN=` format.

Authentication is optional. If authentication is not configured, no credentials are generated. ACLs and quotas set for the user are configured in the `` format suitable for SASL authentication.
|authorization
|xref:type-KafkaUserAuthorizationSimple-{context}[`KafkaUserAuthorizationSimple`]
|Authorization rules for this Kafka user.
|quotas
|xref:type-KafkaUserQuotas-{context}[`KafkaUserQuotas`]
|Quotas on requests to control the broker resources used by clients. Network bandwidth and request rate quotas can be enforced. For more information, see the Apache Kafka design documentation about quotas.
|template
|xref:type-KafkaUserTemplate-{context}[`KafkaUserTemplate`]
|Template to specify how Kafka User `Secrets` are generated.
|====

[id='type-KafkaUserTlsClientAuthentication-{context}']
= `KafkaUserTlsClientAuthentication` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]


The `type` property is a discriminator that distinguishes use of the `KafkaUserTlsClientAuthentication` type from xref:type-KafkaUserTlsExternalClientAuthentication-{context}[`KafkaUserTlsExternalClientAuthentication`], xref:type-KafkaUserScramSha512ClientAuthentication-{context}[`KafkaUserScramSha512ClientAuthentication`].
It must have the value `tls` for the type `KafkaUserTlsClientAuthentication`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `tls`.
|validityDays
|integer
|Number of days for which the user certificate is valid. Both this property and `renewalDays` must be configured together.The value must be greater than 0 and greater than `renewalDays`.If not configured, the Clients CA configuration is used.
|renewalDays
|integer
|Number of days before certificate expiration when the user certificate is renewed. Both this property and `validityDays` must be configured together.The value must be greater than 0 and less than `validityDays`.If not configured, the Clients CA configuration is used.
|====

[id='type-KafkaUserTlsExternalClientAuthentication-{context}']
= `KafkaUserTlsExternalClientAuthentication` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]


The `type` property is a discriminator that distinguishes use of the `KafkaUserTlsExternalClientAuthentication` type from xref:type-KafkaUserTlsClientAuthentication-{context}[`KafkaUserTlsClientAuthentication`], xref:type-KafkaUserScramSha512ClientAuthentication-{context}[`KafkaUserScramSha512ClientAuthentication`].
It must have the value `tls-external` for the type `KafkaUserTlsExternalClientAuthentication`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `tls-external`.
|====

[id='type-KafkaUserScramSha512ClientAuthentication-{context}']
= `KafkaUserScramSha512ClientAuthentication` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]


The `type` property is a discriminator that distinguishes use of the `KafkaUserScramSha512ClientAuthentication` type from xref:type-KafkaUserTlsClientAuthentication-{context}[`KafkaUserTlsClientAuthentication`], xref:type-KafkaUserTlsExternalClientAuthentication-{context}[`KafkaUserTlsExternalClientAuthentication`].
It must have the value `scram-sha-512` for the type `KafkaUserScramSha512ClientAuthentication`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `scram-sha-512`.
|password
|xref:type-Password-{context}[`Password`]
|Specify the password for the user. If not set, a new password is generated by the User Operator.
|====

[id='type-Password-{context}']
= `Password` schema reference

Used in: xref:type-KafkaUserScramSha512ClientAuthentication-{context}[`KafkaUserScramSha512ClientAuthentication`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|valueFrom
|xref:type-PasswordSource-{context}[`PasswordSource`]
|Secret from which the password should be read.
|====

[id='type-KafkaUserAuthorizationSimple-{context}']
= `KafkaUserAuthorizationSimple` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]


The `type` property is a discriminator that distinguishes use of the `KafkaUserAuthorizationSimple` type from other subtypes that may be added in the future.
It must have the value `simple` for the type `KafkaUserAuthorizationSimple`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `simple`.
|acls
|xref:type-AclRule-{context}[`AclRule`] array
|List of ACL rules which should be applied to this user.
|====

[id='type-AclRule-{context}']
= `AclRule` schema reference

Used in: xref:type-KafkaUserAuthorizationSimple-{context}[`KafkaUserAuthorizationSimple`]

xref:type-AclRule-schema-{context}[Full list of `AclRule` schema properties]

include::../api/io.strimzi.api.kafka.model.user.acl.AclRule.adoc[leveloffset=+1]

[id='type-AclRule-schema-{context}']
== `AclRule` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string (one of [allow, deny])
|The type of the rule. ACL rules with type `allow` are used to allow user to execute the specified operations. ACL rules with type `deny` are used to deny user to execute the specified operations. Default value is `allow`.
|resource
|xref:type-AclRuleTopicResource-{context}[`AclRuleTopicResource`], xref:type-AclRuleGroupResource-{context}[`AclRuleGroupResource`], xref:type-AclRuleClusterResource-{context}[`AclRuleClusterResource`], xref:type-AclRuleTransactionalIdResource-{context}[`AclRuleTransactionalIdResource`]
|Indicates the resource for which given ACL rule applies.
|host
|string
|The host from which the action described in the ACL rule is allowed or denied. If not set, it defaults to `*`, allowing or denying the action from any host.
|operations
|string (one or more of [Read, Write, Delete, Alter, Describe, All, IdempotentWrite, ClusterAction, Create, AlterConfigs, DescribeConfigs]) array
|List of operations to allow or deny. Supported operations are: Read, Write, Create, Delete, Alter, Describe, ClusterAction, AlterConfigs, DescribeConfigs, IdempotentWrite and All. Only certain operations work with the specified resource.
|====

[id='type-AclRuleTopicResource-{context}']
= `AclRuleTopicResource` schema reference

Used in: xref:type-AclRule-{context}[`AclRule`]


The `type` property is a discriminator that distinguishes use of the `AclRuleTopicResource` type from xref:type-AclRuleGroupResource-{context}[`AclRuleGroupResource`], xref:type-AclRuleClusterResource-{context}[`AclRuleClusterResource`], xref:type-AclRuleTransactionalIdResource-{context}[`AclRuleTransactionalIdResource`].
It must have the value `topic` for the type `AclRuleTopicResource`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `topic`.
|name
|string
|Name of resource for which given ACL rule applies. Can be combined with `patternType` field to use prefix pattern.
|patternType
|string (one of [prefix, literal])
|Describes the pattern used in the resource field. The supported types are `literal` and `prefix`. With `literal` pattern type, the resource field will be used as a definition of a full topic name. With `prefix` pattern type, the resource name will be used only as a prefix. Default value is `literal`.
|====

[id='type-AclRuleGroupResource-{context}']
= `AclRuleGroupResource` schema reference

Used in: xref:type-AclRule-{context}[`AclRule`]


The `type` property is a discriminator that distinguishes use of the `AclRuleGroupResource` type from xref:type-AclRuleTopicResource-{context}[`AclRuleTopicResource`], xref:type-AclRuleClusterResource-{context}[`AclRuleClusterResource`], xref:type-AclRuleTransactionalIdResource-{context}[`AclRuleTransactionalIdResource`].
It must have the value `group` for the type `AclRuleGroupResource`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `group`.
|name
|string
|Name of resource for which given ACL rule applies. Can be combined with `patternType` field to use prefix pattern.
|patternType
|string (one of [prefix, literal])
|Describes the pattern used in the resource field. The supported types are `literal` and `prefix`. With `literal` pattern type, the resource field will be used as a definition of a full topic name. With `prefix` pattern type, the resource name will be used only as a prefix. Default value is `literal`.
|====

[id='type-AclRuleClusterResource-{context}']
= `AclRuleClusterResource` schema reference

Used in: xref:type-AclRule-{context}[`AclRule`]


The `type` property is a discriminator that distinguishes use of the `AclRuleClusterResource` type from xref:type-AclRuleTopicResource-{context}[`AclRuleTopicResource`], xref:type-AclRuleGroupResource-{context}[`AclRuleGroupResource`], xref:type-AclRuleTransactionalIdResource-{context}[`AclRuleTransactionalIdResource`].
It must have the value `cluster` for the type `AclRuleClusterResource`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `cluster`.
|====

[id='type-AclRuleTransactionalIdResource-{context}']
= `AclRuleTransactionalIdResource` schema reference

Used in: xref:type-AclRule-{context}[`AclRule`]


The `type` property is a discriminator that distinguishes use of the `AclRuleTransactionalIdResource` type from xref:type-AclRuleTopicResource-{context}[`AclRuleTopicResource`], xref:type-AclRuleGroupResource-{context}[`AclRuleGroupResource`], xref:type-AclRuleClusterResource-{context}[`AclRuleClusterResource`].
It must have the value `transactionalId` for the type `AclRuleTransactionalIdResource`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `transactionalId`.
|name
|string
|Name of resource for which given ACL rule applies. Can be combined with `patternType` field to use prefix pattern.
|patternType
|string (one of [prefix, literal])
|Describes the pattern used in the resource field. The supported types are `literal` and `prefix`. With `literal` pattern type, the resource field will be used as a definition of a full name. With `prefix` pattern type, the resource name will be used only as a prefix. Default value is `literal`.
|====

[id='type-KafkaUserQuotas-{context}']
= `KafkaUserQuotas` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]

xref:type-KafkaUserQuotas-schema-{context}[Full list of `KafkaUserQuotas` schema properties]

include::../api/io.strimzi.api.kafka.model.user.KafkaUserQuotas.adoc[leveloffset=+1]

[id='type-KafkaUserQuotas-schema-{context}']
== `KafkaUserQuotas` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|producerByteRate
|integer
|A quota on the maximum bytes per-second that each client group can publish to a broker before the clients in the group are throttled. Defined on a per-broker basis.
|consumerByteRate
|integer
|A quota on the maximum bytes per-second that each client group can fetch from a broker before the clients in the group are throttled. Defined on a per-broker basis.
|requestPercentage
|integer
|A quota on the maximum CPU utilization of each client group as a percentage of network and I/O threads.
|controllerMutationRate
|number
|A quota on the rate at which mutations are accepted for the create topics request, the create partitions request and the delete topics request. The rate is accumulated by the number of partitions created or deleted.
|====

[id='type-KafkaUserTemplate-{context}']
= `KafkaUserTemplate` schema reference

Used in: xref:type-KafkaUserSpec-{context}[`KafkaUserSpec`]

xref:type-KafkaUserTemplate-schema-{context}[Full list of `KafkaUserTemplate` schema properties]

include::../api/io.strimzi.api.kafka.model.user.KafkaUserTemplate.adoc[leveloffset=+1]

[id='type-KafkaUserTemplate-schema-{context}']
== `KafkaUserTemplate` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|secret
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for KafkaUser resources. The template allows users to specify how the `Secret` with password or TLS certificates is generated.
|====

[id='type-KafkaUserStatus-{context}']
= `KafkaUserStatus` schema reference

Used in: xref:type-KafkaUser-{context}[`KafkaUser`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|username
|string
|Username.
|secret
|string
|The name of `Secret` where the credentials are stored.
|====

[id='type-KafkaBridge-{context}']
= `KafkaBridge` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]
|The specification of the HTTP Bridge.
|status
|xref:type-KafkaBridgeStatus-{context}[`KafkaBridgeStatus`]
|The status of the HTTP Bridge.
|====

[id='type-KafkaBridgeSpec-{context}']
= `KafkaBridgeSpec` schema reference

Used in: xref:type-KafkaBridge-{context}[`KafkaBridge`]

xref:type-KafkaBridgeSpec-schema-{context}[Full list of `KafkaBridgeSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.bridge.KafkaBridgeSpec.adoc[leveloffset=+1]

[id='type-KafkaBridgeSpec-schema-{context}']
== `KafkaBridgeSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|replicas
|integer
|The number of pods in the `Deployment`. Required in the `v1` version of the Strimzi API.
|image
|string
|The container image used for HTTP Bridge pods. If no image name is explicitly specified, the image name corresponds to the image specified in the Cluster Operator configuration. If an image name is not defined in the Cluster Operator configuration, a default value is used.
|bootstrapServers
|string
|A list of host:port pairs for establishing the initial connection to the Kafka cluster.
|tls
|xref:type-ClientTls-{context}[`ClientTls`]
|TLS configuration for connecting HTTP Bridge to the cluster.
|authentication
|xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`]
|Authentication configuration for connecting to the cluster.
|http
|xref:type-KafkaBridgeHttpConfig-{context}[`KafkaBridgeHttpConfig`]
|The HTTP related configuration.
|adminClient
|xref:type-KafkaBridgeAdminClientSpec-{context}[`KafkaBridgeAdminClientSpec`]
|Kafka AdminClient related configuration.
|consumer
|xref:type-KafkaBridgeConsumerSpec-{context}[`KafkaBridgeConsumerSpec`]
|Kafka consumer related configuration.
|producer
|xref:type-KafkaBridgeProducerSpec-{context}[`KafkaBridgeProducerSpec`]
|Kafka producer related configuration.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration for HTTP Bridge.
|clientRackInitImage
|string
|The image of the init container used for initializing the `client.rack`.
|rack
|xref:type-TopologyLabelRack-{context}[`TopologyLabelRack`], xref:type-EnvironmentVariableRack-{context}[`EnvironmentVariableRack`]
|Configuration of the node label which will be used as the client.rack consumer configuration.
|metricsConfig
|xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`], xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]
|Metrics configuration.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|template
|xref:type-KafkaBridgeTemplate-{context}[`KafkaBridgeTemplate`]
|Template for HTTP Bridge resources. The template allows users to specify how a `Deployment` and `Pod` is generated.
|tracing
|xref:type-OpenTelemetryTracing-{context}[`OpenTelemetryTracing`]
|The configuration of tracing in HTTP Bridge.
|config
|map
|Additional configuration for the HTTP bridge. The following prefixes cannot be set: kafka., http., bridge.metrics. The following options cannot be set: bridge.id, bridge.tracing, bridge.metrics.
|====

[id='type-KafkaBridgeHttpConfig-{context}']
= `KafkaBridgeHttpConfig` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]

xref:type-KafkaBridgeHttpConfig-schema-{context}[Full list of `KafkaBridgeHttpConfig` schema properties]

include::../api/io.strimzi.api.kafka.model.bridge.KafkaBridgeHttpConfig.adoc[leveloffset=+1]

[id='type-KafkaBridgeHttpConfig-schema-{context}']
== `KafkaBridgeHttpConfig` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|port
|integer
|Port the server listens on.
|tls
|xref:type-KafkaBridgeHttpTls-{context}[`KafkaBridgeHttpTls`]
|TLS configuration for clients connections to the HTTP Bridge.
|cors
|xref:type-KafkaBridgeHttpCors-{context}[`KafkaBridgeHttpCors`]
|CORS configuration for the HTTP Bridge.
|====

[id='type-KafkaBridgeHttpTls-{context}']
= `KafkaBridgeHttpTls` schema reference

Used in: xref:type-KafkaBridgeHttpConfig-{context}[`KafkaBridgeHttpConfig`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|certificateAndKey
|xref:type-CertAndKeySecretSource-{context}[`CertAndKeySecretSource`]
|Reference to the `Secret` which holds the certificate and private key pair.
|config
|map
|Additional configuration for the HTTP server TLS. Properties with the following prefixes cannot be set: ssl. (with the exception of: ssl.enabled.cipher.suites, ssl.enabled.protocols).
|====

[id='type-KafkaBridgeHttpCors-{context}']
= `KafkaBridgeHttpCors` schema reference

Used in: xref:type-KafkaBridgeHttpConfig-{context}[`KafkaBridgeHttpConfig`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|allowedOrigins
|string array
|List of allowed origins. Java regular expressions can be used.
|allowedMethods
|string array
|List of allowed HTTP methods.
|====

[id='type-KafkaBridgeAdminClientSpec-{context}']
= `KafkaBridgeAdminClientSpec` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|config
|map
|The Kafka AdminClient configuration used for AdminClient instances created by the bridge.
|====

[id='type-KafkaBridgeConsumerSpec-{context}']
= `KafkaBridgeConsumerSpec` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]

xref:type-KafkaBridgeConsumerSpec-schema-{context}[Full list of `KafkaBridgeConsumerSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.bridge.KafkaBridgeConsumerSpec.adoc[leveloffset=+1]

[id='type-KafkaBridgeConsumerSpec-schema-{context}']
== `KafkaBridgeConsumerSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|enabled
|boolean
|Whether the HTTP consumer should be enabled or disabled. The default is enabled (`true`).
|timeoutSeconds
|integer
|The timeout in seconds for deleting inactive consumers, default is -1 (disabled).
|config
|map
|The Kafka consumer configuration used for consumer instances created by the bridge. Properties with the following prefixes cannot be set: ssl., bootstrap.servers, group.id, sasl., security. (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols).
|====

[id='type-KafkaBridgeProducerSpec-{context}']
= `KafkaBridgeProducerSpec` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]

xref:type-KafkaBridgeProducerSpec-schema-{context}[Full list of `KafkaBridgeProducerSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.bridge.KafkaBridgeProducerSpec.adoc[leveloffset=+1]

[id='type-KafkaBridgeProducerSpec-schema-{context}']
== `KafkaBridgeProducerSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|enabled
|boolean
|Whether the HTTP producer should be enabled or disabled. The default is enabled (`true`).
|config
|map
|The Kafka producer configuration used for producer instances created by the bridge. Properties with the following prefixes cannot be set: ssl., bootstrap.servers, sasl., security. (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols).
|====

[id='type-KafkaBridgeTemplate-{context}']
= `KafkaBridgeTemplate` schema reference

Used in: xref:type-KafkaBridgeSpec-{context}[`KafkaBridgeSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|deployment
|xref:type-DeploymentTemplate-{context}[`DeploymentTemplate`]
|Template for HTTP Bridge `Deployment`.
|pod
|xref:type-PodTemplate-{context}[`PodTemplate`]
|Template for HTTP Bridge `Pods`.
|apiService
|xref:type-InternalServiceTemplate-{context}[`InternalServiceTemplate`]
|Template for HTTP Bridge API `Service`.
|podDisruptionBudget
|xref:type-PodDisruptionBudgetTemplate-{context}[`PodDisruptionBudgetTemplate`]
|Template for HTTP Bridge `PodDisruptionBudget`.
|bridgeContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the HTTP Bridge container.
|clusterRoleBinding
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the HTTP Bridge ClusterRoleBinding.
|serviceAccount
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for the HTTP Bridge service account.
|initContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the HTTP Bridge init container.
|====

[id='type-KafkaBridgeStatus-{context}']
= `KafkaBridgeStatus` schema reference

Used in: xref:type-KafkaBridge-{context}[`KafkaBridge`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|url
|string
|The URL at which external client applications can access the HTTP Bridge.
|replicas
|integer
|The current number of pods being used to provide this resource.
|labelSelector
|string
|Label selector for pods providing this resource.
|====

[id='type-KafkaConnector-{context}']
= `KafkaConnector` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaConnectorSpec-{context}[`KafkaConnectorSpec`]
|The specification of the Kafka Connector.
|status
|xref:type-KafkaConnectorStatus-{context}[`KafkaConnectorStatus`]
|The status of the Kafka Connector.
|====

[id='type-KafkaConnectorSpec-{context}']
= `KafkaConnectorSpec` schema reference

Used in: xref:type-KafkaConnector-{context}[`KafkaConnector`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|class
|string
|The Class for the Kafka Connector.
|tasksMax
|integer
|The maximum number of tasks for the Kafka Connector.
|autoRestart
|xref:type-AutoRestart-{context}[`AutoRestart`]
|Automatic restart of connector and tasks configuration.
|version
|string
|Desired version or version range to respect when starting the Kafka Connector. This is only supported when using Kafka Connect version 4.1.0 and higher.
|config
|map
|The Kafka Connector configuration. The following properties cannot be set: name, connector.class, tasks.max, connector.plugin.version.
|state
|string (one of [running, paused, stopped])
|The state the connector should be in. Defaults to running.
|listOffsets
|xref:type-ListOffsets-{context}[`ListOffsets`]
|Configuration for listing offsets.
|alterOffsets
|xref:type-AlterOffsets-{context}[`AlterOffsets`]
|Configuration for altering offsets.
|====

[id='type-AutoRestart-{context}']
= `AutoRestart` schema reference

Used in: xref:type-KafkaConnectorSpec-{context}[`KafkaConnectorSpec`], xref:type-KafkaMirrorMaker2ConnectorSpec-{context}[`KafkaMirrorMaker2ConnectorSpec`]

xref:type-AutoRestart-schema-{context}[Full list of `AutoRestart` schema properties]

include::../api/io.strimzi.api.kafka.model.connector.AutoRestart.adoc[leveloffset=+1]

[id='type-AutoRestart-schema-{context}']
== `AutoRestart` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|enabled
|boolean
|Whether automatic restart for failed connectors and tasks should be enabled or disabled.
|maxRestarts
|integer
|The maximum number of connector restarts that the operator will try. If the connector remains in a failed state after reaching this limit, it must be restarted manually by the user. Defaults to an unlimited number of restarts.
|====

[id='type-ListOffsets-{context}']
= `ListOffsets` schema reference

Used in: xref:type-KafkaConnectorSpec-{context}[`KafkaConnectorSpec`], xref:type-KafkaMirrorMaker2ConnectorSpec-{context}[`KafkaMirrorMaker2ConnectorSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|toConfigMap
|xref:type-LocalObjectReference-{context}[`LocalObjectReference`]
|Reference to the ConfigMap where the list of offsets will be written to.
|====

[id='type-AlterOffsets-{context}']
= `AlterOffsets` schema reference

Used in: xref:type-KafkaConnectorSpec-{context}[`KafkaConnectorSpec`], xref:type-KafkaMirrorMaker2ConnectorSpec-{context}[`KafkaMirrorMaker2ConnectorSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|fromConfigMap
|xref:type-LocalObjectReference-{context}[`LocalObjectReference`]
|Reference to the ConfigMap where the new offsets are stored.
|====

[id='type-KafkaConnectorStatus-{context}']
= `KafkaConnectorStatus` schema reference

Used in: xref:type-KafkaConnector-{context}[`KafkaConnector`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|autoRestart
|xref:type-AutoRestartStatus-{context}[`AutoRestartStatus`]
|The auto restart status.
|connectorStatus
|map
|The connector status, as reported by the Kafka Connect REST API.
|tasksMax
|integer
|The maximum number of tasks for the Kafka Connector.
|topics
|string array
|The list of topics used by the Kafka Connector.
|====

[id='type-AutoRestartStatus-{context}']
= `AutoRestartStatus` schema reference

Used in: xref:type-KafkaConnectorStatus-{context}[`KafkaConnectorStatus`], xref:type-KafkaMirrorMaker2Status-{context}[`KafkaMirrorMaker2Status`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|count
|integer
|The number of times the connector or task is restarted.
|connectorName
|string
|The name of the connector being restarted.
|lastRestartTimestamp
|string
|The last time the automatic restart was attempted. The required format is 'yyyy-MM-ddTHH:mm:ssZ' in the UTC time zone.
|====

[id='type-KafkaMirrorMaker2-{context}']
= `KafkaMirrorMaker2` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]
|The specification of the Kafka MirrorMaker 2 cluster.
|status
|xref:type-KafkaMirrorMaker2Status-{context}[`KafkaMirrorMaker2Status`]
|The status of the Kafka MirrorMaker 2 cluster.
|====

[id='type-KafkaMirrorMaker2Spec-{context}']
= `KafkaMirrorMaker2Spec` schema reference

Used in: xref:type-KafkaMirrorMaker2-{context}[`KafkaMirrorMaker2`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|version
|string
|The Kafka Connect version. Defaults to the latest version. Consult the user documentation to understand the process required to upgrade or downgrade the version.
|replicas
|integer
|The number of pods in the Kafka Connect group. Required in the `v1` version of the Strimzi API.
|image
|string
|The container image used for Kafka Connect pods. If no image name is explicitly specified, it is determined based on the `spec.version` configuration. The image names are specifically mapped to corresponding versions in the Cluster Operator configuration.
|target
|xref:type-KafkaMirrorMaker2TargetClusterSpec-{context}[`KafkaMirrorMaker2TargetClusterSpec`]
|The target Apache Kafka cluster. The target Kafka cluster is used by the underlying Kafka Connect framework for its internal topics.
|mirrors
|xref:type-KafkaMirrorMaker2MirrorSpec-{context}[`KafkaMirrorMaker2MirrorSpec`] array
|Configuration of the MirrorMaker 2 connectors.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|The maximum limits for CPU and memory resources and the requested initial resources.
|livenessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod liveness checking.
|readinessProbe
|xref:type-StrimziProbe-{context}[`StrimziProbe`]
|Pod readiness checking.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|jmxOptions
|xref:type-KafkaJmxOptions-{context}[`KafkaJmxOptions`]
|JMX Options.
|logging
|xref:type-InlineLogging-{context}[`InlineLogging`], xref:type-ExternalLogging-{context}[`ExternalLogging`]
|Logging configuration for Kafka Connect.
|clientRackInitImage
|string
|The image of the init container used for initializing the `client.rack`.
|rack
|xref:type-TopologyLabelRack-{context}[`TopologyLabelRack`], xref:type-EnvironmentVariableRack-{context}[`EnvironmentVariableRack`]
|Configuration of the node label which will be used as the `client.rack` consumer configuration.
|metricsConfig
|xref:type-JmxPrometheusExporterMetrics-{context}[`JmxPrometheusExporterMetrics`], xref:type-StrimziMetricsReporter-{context}[`StrimziMetricsReporter`]
|Metrics configuration.
|tracing
|xref:type-OpenTelemetryTracing-{context}[`OpenTelemetryTracing`]
|The configuration of tracing in Kafka Connect.
|template
|xref:type-KafkaConnectTemplate-{context}[`KafkaConnectTemplate`]
|Template for Kafka Connect and Kafka MirrorMaker 2 resources. The template allows users to specify how the `Pods`, `Service`, and other services are generated.
|====

[id='type-KafkaMirrorMaker2TargetClusterSpec-{context}']
= `KafkaMirrorMaker2TargetClusterSpec` schema reference

Used in: xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]

xref:type-KafkaMirrorMaker2TargetClusterSpec-schema-{context}[Full list of `KafkaMirrorMaker2TargetClusterSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.mirrormaker2.KafkaMirrorMaker2TargetClusterSpec.adoc[leveloffset=+1]

[id='type-KafkaMirrorMaker2TargetClusterSpec-schema-{context}']
== `KafkaMirrorMaker2TargetClusterSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|alias
|string
|Alias used to reference the Kafka cluster.
|bootstrapServers
|string
|A comma-separated list of `host:port` pairs for establishing the connection to the Kafka cluster.
|groupId
|string
|A unique ID that identifies the Connect cluster group. Required.
|configStorageTopic
|string
|The name of the Kafka topic where connector configurations are stored. Required.
|statusStorageTopic
|string
|The name of the Kafka topic where connector and task statuses are stored. Required.
|offsetStorageTopic
|string
|The name of the Kafka topic where source connector offsets are stored. Required.
|tls
|xref:type-ClientTls-{context}[`ClientTls`]
|TLS configuration for connecting MirrorMaker 2 connectors to a cluster.
|authentication
|xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`]
|Authentication configuration for connecting to the cluster.
|config
|map
|The MirrorMaker 2 cluster config. Properties with the following prefixes cannot be set: group.id, config.storage.topic, offset.storage.topic, status.storage.topic, ssl., sasl., security., listeners, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, rest.extension.classes).
|====

[id='type-KafkaMirrorMaker2MirrorSpec-{context}']
= `KafkaMirrorMaker2MirrorSpec` schema reference

Used in: xref:type-KafkaMirrorMaker2Spec-{context}[`KafkaMirrorMaker2Spec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|source
|xref:type-KafkaMirrorMaker2ClusterSpec-{context}[`KafkaMirrorMaker2ClusterSpec`]
|The source Apache Kafka cluster. The source Kafka cluster is used by the Kafka MirrorMaker 2 connectors.
|sourceConnector
|xref:type-KafkaMirrorMaker2ConnectorSpec-{context}[`KafkaMirrorMaker2ConnectorSpec`]
|The specification of the Kafka MirrorMaker 2 source connector.
|checkpointConnector
|xref:type-KafkaMirrorMaker2ConnectorSpec-{context}[`KafkaMirrorMaker2ConnectorSpec`]
|The specification of the Kafka MirrorMaker 2 checkpoint connector.
|topicsPattern
|string
|A regular expression matching the topics to be mirrored, for example, "topic1\|topic2\|topic3". Comma-separated lists are also supported.
|topicsExcludePattern
|string
|A regular expression matching the topics to exclude from mirroring. Comma-separated lists are also supported.
|groupsPattern
|string
|A regular expression matching the consumer groups to be mirrored. Comma-separated lists are also supported.
|groupsExcludePattern
|string
|A regular expression matching the consumer groups to exclude from mirroring. Comma-separated lists are also supported.
|====

[id='type-KafkaMirrorMaker2ClusterSpec-{context}']
= `KafkaMirrorMaker2ClusterSpec` schema reference

Used in: xref:type-KafkaMirrorMaker2MirrorSpec-{context}[`KafkaMirrorMaker2MirrorSpec`]

xref:type-KafkaMirrorMaker2ClusterSpec-schema-{context}[Full list of `KafkaMirrorMaker2ClusterSpec` schema properties]

include::../api/io.strimzi.api.kafka.model.mirrormaker2.KafkaMirrorMaker2ClusterSpec.adoc[leveloffset=+1]

[id='type-KafkaMirrorMaker2ClusterSpec-schema-{context}']
== `KafkaMirrorMaker2ClusterSpec` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|alias
|string
|Alias used to reference the Kafka cluster.
|bootstrapServers
|string
|A comma-separated list of `host:port` pairs for establishing the connection to the Kafka cluster.
|tls
|xref:type-ClientTls-{context}[`ClientTls`]
|TLS configuration for connecting MirrorMaker 2 connectors to a cluster.
|authentication
|xref:type-KafkaClientAuthenticationTls-{context}[`KafkaClientAuthenticationTls`], xref:type-KafkaClientAuthenticationScramSha256-{context}[`KafkaClientAuthenticationScramSha256`], xref:type-KafkaClientAuthenticationScramSha512-{context}[`KafkaClientAuthenticationScramSha512`], xref:type-KafkaClientAuthenticationPlain-{context}[`KafkaClientAuthenticationPlain`], xref:type-KafkaClientAuthenticationCustom-{context}[`KafkaClientAuthenticationCustom`]
|Authentication configuration for connecting to the cluster.
|config
|map
|The MirrorMaker 2 cluster config. Properties with the following prefixes cannot be set: group.id, config.storage.topic, offset.storage.topic, status.storage.topic, ssl., sasl., security., listeners, plugin.path, rest., bootstrap.servers, consumer.interceptor.classes, producer.interceptor.classes (with the exception of: ssl.endpoint.identification.algorithm, ssl.cipher.suites, ssl.protocol, ssl.enabled.protocols, rest.extension.classes).
|====

[id='type-KafkaMirrorMaker2ConnectorSpec-{context}']
= `KafkaMirrorMaker2ConnectorSpec` schema reference

Used in: xref:type-KafkaMirrorMaker2MirrorSpec-{context}[`KafkaMirrorMaker2MirrorSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|tasksMax
|integer
|The maximum number of tasks for the Kafka Connector.
|version
|string
|Desired version or version range to respect when starting the Kafka Connector. This is only supported when using Kafka Connect version 4.1.0 and higher.
|config
|map
|The Kafka Connector configuration. The following properties cannot be set: name, connector.class, tasks.max, connector.plugin.version.
|state
|string (one of [running, paused, stopped])
|The state the connector should be in. Defaults to running.
|autoRestart
|xref:type-AutoRestart-{context}[`AutoRestart`]
|Automatic restart of connector and tasks configuration.
|listOffsets
|xref:type-ListOffsets-{context}[`ListOffsets`]
|Configuration for listing offsets.
|alterOffsets
|xref:type-AlterOffsets-{context}[`AlterOffsets`]
|Configuration for altering offsets.
|====

[id='type-KafkaMirrorMaker2Status-{context}']
= `KafkaMirrorMaker2Status` schema reference

Used in: xref:type-KafkaMirrorMaker2-{context}[`KafkaMirrorMaker2`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|url
|string
|The URL of the REST API endpoint for managing and monitoring Kafka Connect connectors.
|connectors
|map array
|List of MirrorMaker 2 connector statuses, as reported by the Kafka Connect REST API.
|autoRestartStatuses
|xref:type-AutoRestartStatus-{context}[`AutoRestartStatus`] array
|List of MirrorMaker 2 connector auto restart statuses.
|connectorPlugins
|xref:type-ConnectorPlugin-{context}[`ConnectorPlugin`] array
|The list of connector plugins available in this Kafka Connect deployment.
|labelSelector
|string
|Label selector for pods providing this resource.
|replicas
|integer
|The current number of pods being used to provide this resource.
|====

[id='type-KafkaRebalance-{context}']
= `KafkaRebalance` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaRebalanceSpec-{context}[`KafkaRebalanceSpec`]
|The specification of the Kafka rebalance.
|status
|xref:type-KafkaRebalanceStatus-{context}[`KafkaRebalanceStatus`]
|The status of the Kafka rebalance.
|====

[id='type-KafkaRebalanceSpec-{context}']
= `KafkaRebalanceSpec` schema reference

Used in: xref:type-KafkaRebalance-{context}[`KafkaRebalance`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|mode
|string (one of [remove-disks, remove-brokers, full, add-brokers])
|Mode to run the rebalancing. The supported modes are `full`, `add-brokers`, `remove-brokers`.
If not specified, the `full` mode is used by default. 

* `full` mode runs the rebalancing across all the brokers in the cluster.
* `add-brokers` mode can be used after scaling up the cluster to move some replicas to the newly added brokers.
* `remove-brokers` mode can be used before scaling down the cluster to move replicas out of the brokers to be removed.
* `remove-disks` mode can be used to move data across the volumes within the same broker
.
|brokers
|integer array
|The list of newly added brokers in case of scaling up or the ones to be removed in case of scaling down to use for rebalancing. This list can be used only with rebalancing mode `add-brokers` and `removed-brokers`. It is ignored with `full` mode.
|goals
|string array
|A list of goals, ordered by decreasing priority, to use for generating and executing the rebalance proposal. The supported goals are available at https://github.com/linkedin/cruise-control#goals. If an empty goals list is provided, the goals declared in the default.goals Cruise Control configuration parameter are used.
|skipHardGoalCheck
|boolean
|Whether to allow the hard goals specified in the Kafka CR to be skipped in optimization proposal generation. This can be useful when some of those hard goals are preventing a balance solution being found. Default is false.
|rebalanceDisk
|boolean
|Enables intra-broker disk balancing, which balances disk space utilization between disks on the same broker. Only applies to Kafka deployments that use JBOD storage with multiple disks. When enabled, inter-broker balancing is disabled. Default is false.
|excludedTopics
|string
|A regular expression where any matching topics will be excluded from the calculation of optimization proposals. This expression will be parsed by the java.util.regex.Pattern class; for more information on the supported format consult the documentation for that class.
|concurrentPartitionMovementsPerBroker
|integer
|The upper bound of ongoing partition replica movements going into/out of each broker. Default is 5.
|concurrentIntraBrokerPartitionMovements
|integer
|The upper bound of ongoing partition replica movements between disks within each broker. Default is 2.
|concurrentLeaderMovements
|integer
|The upper bound of ongoing partition leadership movements. Default is 1000.
|replicationThrottle
|integer
|The upper bound, in bytes per second, on the bandwidth used to move replicas. There is no limit by default.
|replicaMovementStrategies
|string array
|A list of strategy class names used to determine the execution order for the replica movements in the generated optimization proposal. By default BaseReplicaMovementStrategy is used, which will execute the replica movements in the order that they were generated.
|moveReplicasOffVolumes
|xref:type-BrokerAndVolumeIds-{context}[`BrokerAndVolumeIds`] array
|List of brokers and their corresponding volumes from which replicas need to be moved.
|====

[id='type-BrokerAndVolumeIds-{context}']
= `BrokerAndVolumeIds` schema reference

Used in: xref:type-KafkaRebalanceSpec-{context}[`KafkaRebalanceSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|brokerId
|integer
|ID of the broker that contains the disk from which you want to move the partition replicas.
|volumeIds
|integer array
|IDs of the disks from which the partition replicas need to be moved.
|====

[id='type-KafkaRebalanceStatus-{context}']
= `KafkaRebalanceStatus` schema reference

Used in: xref:type-KafkaRebalance-{context}[`KafkaRebalance`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|sessionId
|string
|The session identifier for requests to Cruise Control pertaining to this KafkaRebalance resource. This is used by the Kafka Rebalance operator to track the status of ongoing rebalancing operations.
|progress
|xref:type-KafkaRebalanceProgress-{context}[`KafkaRebalanceProgress`]
|A reference to Config Map with the progress information.
|optimizationResult
|map
|A JSON object describing the optimization result.
|====

[id='type-KafkaRebalanceProgress-{context}']
= `KafkaRebalanceProgress` schema reference

Used in: xref:type-KafkaRebalanceStatus-{context}[`KafkaRebalanceStatus`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|rebalanceProgressConfigMap
|string
|The name of the `ConfigMap` containing information related to the progress of a partition rebalance.
|====

[id='type-KafkaNodePool-{context}']
= `KafkaNodePool` schema reference


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]
|The specification of the KafkaNodePool.
|status
|xref:type-KafkaNodePoolStatus-{context}[`KafkaNodePoolStatus`]
|The status of the KafkaNodePool.
|====

[id='type-KafkaNodePoolSpec-{context}']
= `KafkaNodePoolSpec` schema reference

Used in: xref:type-KafkaNodePool-{context}[`KafkaNodePool`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|replicas
|integer
|The number of pods in the pool.
|storage
|xref:type-EphemeralStorage-{context}[`EphemeralStorage`], xref:type-PersistentClaimStorage-{context}[`PersistentClaimStorage`], xref:type-JbodStorage-{context}[`JbodStorage`]
|Storage configuration (disk). Cannot be updated.
|roles
|string (one or more of [controller, broker]) array
|The roles assigned to the node pool. Supported values are `broker` and `controller`. This property is required.
|resources
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core[ResourceRequirements]
|CPU and memory resources to reserve.
|jvmOptions
|xref:type-JvmOptions-{context}[`JvmOptions`]
|JVM Options for pods.
|template
|xref:type-KafkaNodePoolTemplate-{context}[`KafkaNodePoolTemplate`]
|Template for pool resources. The template allows users to specify how the resources belonging to this pool are generated.
|====

[id='type-EphemeralStorage-{context}']
= `EphemeralStorage` schema reference

Used in: xref:type-JbodStorage-{context}[`JbodStorage`], xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]


The `type` property is a discriminator that distinguishes use of the `EphemeralStorage` type from xref:type-PersistentClaimStorage-{context}[`PersistentClaimStorage`].
It must have the value `ephemeral` for the type `EphemeralStorage`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|id
|integer
|Storage identification number. It is mandatory only for storage volumes defined in a storage of type 'jbod'.
|sizeLimit
|string
|When type=ephemeral, defines the total amount of local storage required for this EmptyDir volume (for example 1Gi).
|type
|string
|Must be `ephemeral`.
|kraftMetadata
|string (one of [shared])
|Specifies whether this volume should be used for storing KRaft metadata. This property is optional. When set, the only currently supported value is `shared`. At most one volume can have this property set.
|====

[id='type-PersistentClaimStorage-{context}']
= `PersistentClaimStorage` schema reference

Used in: xref:type-JbodStorage-{context}[`JbodStorage`], xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]


The `type` property is a discriminator that distinguishes use of the `PersistentClaimStorage` type from xref:type-EphemeralStorage-{context}[`EphemeralStorage`].
It must have the value `persistent-claim` for the type `PersistentClaimStorage`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|id
|integer
|Storage identification number. It is mandatory only for storage volumes defined in a storage of type 'jbod'.
|type
|string
|Must be `persistent-claim`.
|size
|string
|When `type=persistent-claim`, defines the size of the persistent volume claim, such as 100Gi. Mandatory when `type=persistent-claim`.
|kraftMetadata
|string (one of [shared])
|Specifies whether this volume should be used for storing KRaft metadata. This property is optional. When set, the only currently supported value is `shared`. At most one volume can have this property set.
|class
|string
|The storage class to use for dynamic volume allocation.
|volumeAttributesClass
|string
|Specifies `VolumeAttributeClass` name for dynamically configuring storage attributes.
|selector
|map
|Specifies a specific persistent volume to use. It contains key:value pairs representing labels for selecting such a volume.
|deleteClaim
|boolean
|Specifies whether the persistent volume claim is deleted when a Kafka node is deleted. Optional. Defaults to `false`.
|====

[id='type-JbodStorage-{context}']
= `JbodStorage` schema reference

Used in: xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]


The `type` property is a discriminator that distinguishes use of the `JbodStorage` type from xref:type-EphemeralStorage-{context}[`EphemeralStorage`], xref:type-PersistentClaimStorage-{context}[`PersistentClaimStorage`].
It must have the value `jbod` for the type `JbodStorage`.
[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|type
|string
|Must be `jbod`.
|volumes
|xref:type-EphemeralStorage-{context}[`EphemeralStorage`], xref:type-PersistentClaimStorage-{context}[`PersistentClaimStorage`] array
|List of volumes as Storage objects representing the JBOD disks array.
|====

[id='type-KafkaNodePoolTemplate-{context}']
= `KafkaNodePoolTemplate` schema reference

Used in: xref:type-KafkaNodePoolSpec-{context}[`KafkaNodePoolSpec`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|podSet
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka `StrimziPodSet` resource.
|pod
|xref:type-StatefulPodTemplate-{context}[`StatefulPodTemplate`]
|Template for Kafka `Pods`.
|perPodService
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Services` used for access from outside of Kubernetes.
|perPodRoute
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Routes` used for access from outside of OpenShift.
|perPodIngress
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for Kafka per-pod `Ingress` used for access from outside of Kubernetes.
|persistentVolumeClaim
|xref:type-ResourceTemplate-{context}[`ResourceTemplate`]
|Template for all Kafka `PersistentVolumeClaims`.
|kafkaContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka broker container.
|initContainer
|xref:type-ContainerTemplate-{context}[`ContainerTemplate`]
|Template for the Kafka init container.
|====

[id='type-KafkaNodePoolStatus-{context}']
= `KafkaNodePoolStatus` schema reference

Used in: xref:type-KafkaNodePool-{context}[`KafkaNodePool`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|nodeIds
|integer array
|Node IDs used by Kafka nodes in this pool.
|clusterId
|string
|Kafka cluster ID.
|roles
|string (one or more of [controller, broker]) array
|Added in Strimzi 0.39.0. The roles currently assigned to this pool.
|replicas
|integer
|The current number of pods being used to provide this resource.
|labelSelector
|string
|Label selector for pods providing this resource.
|====

[id='type-StrimziPodSet-{context}']
= `StrimziPodSet` schema reference

xref:type-StrimziPodSet-schema-{context}[Full list of `StrimziPodSet` schema properties]

include::../api/io.strimzi.api.kafka.model.podset.StrimziPodSet.adoc[leveloffset=+1]

[id='type-StrimziPodSet-schema-{context}']
== `StrimziPodSet` schema properties


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|spec
|xref:type-StrimziPodSetSpec-{context}[`StrimziPodSetSpec`]
|The specification of the StrimziPodSet.
|status
|xref:type-StrimziPodSetStatus-{context}[`StrimziPodSetStatus`]
|The status of the StrimziPodSet.
|====

[id='type-StrimziPodSetSpec-{context}']
= `StrimziPodSetSpec` schema reference

Used in: xref:type-StrimziPodSet-{context}[`StrimziPodSet`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|selector
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#labelselector-v1-meta[LabelSelector]
|Selector is a label query which matches all the pods managed by this `StrimziPodSet`. Only `matchLabels` is supported. If `matchExpressions` is set, it will be ignored.
|pods
|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#pods-v1-core[Map] array
|The Pods managed by this StrimziPodSet.
|====

[id='type-StrimziPodSetStatus-{context}']
= `StrimziPodSetStatus` schema reference

Used in: xref:type-StrimziPodSet-{context}[`StrimziPodSet`]


[cols="2,2,3a",options="header"]
|====
|Property |Property type |Description
|conditions
|xref:type-Condition-{context}[`Condition`] array
|List of status conditions.
|observedGeneration
|integer
|The generation of the CRD that was last reconciled by the operator.
|pods
|integer
|Number of pods managed by this `StrimziPodSet` resource.
|readyPods
|integer
|Number of pods managed by this `StrimziPodSet` resource that are ready.
|currentPods
|integer
|Number of pods managed by this `StrimziPodSet` resource that have the current revision.
|====

---

### Documentation Modules Con Common Configuration Properties (`documentation/modules/con-common-configuration-properties.adoc`)

:_mod-docs-content-type: CONCEPT

// This module is included in the following files:
//
// configuring/configuring.adoc

[id='con-common-configuration-properties-{context}']
= Common configuration properties

[role="_abstract"]
Use Common configuration properties to configure Strimzi custom resources.
You add common configuration properties to a custom resource like any other supported configuration for that resource.

[id='con-common-configuration-replicas-{context}']
== `replicas`

Use the `replicas` property to configure replicas.

The type of replication depends on the resource.

* `KafkaTopic` uses a replication factor to configure the number of replicas of each partition within a Kafka cluster.
* Kafka components use replicas to configure the number of pods in a deployment to provide better availability and scalability.

NOTE: When running a Kafka component on Kubernetes it may not be necessary to run multiple replicas for high availability.
When the node where the component is deployed crashes, Kubernetes will automatically reschedule the Kafka component pod to a different node.
However, running Kafka components with multiple replicas can provide faster failover times as the other nodes will be up and running.

[id='con-common-configuration-bootstrap-{context}']
== `bootstrapServers`

Use the `bootstrapServers` property to configure a list of bootstrap servers.

The bootstrap server lists can refer to Kafka clusters that are not deployed in the same Kubernetes cluster.
They can also refer to a Kafka cluster not deployed by Strimzi.

If on the same Kubernetes cluster, each list must ideally contain the Kafka cluster bootstrap service which is named `_CLUSTER-NAME_-kafka-bootstrap` and a port number.
If deployed by Strimzi but on different Kubernetes clusters, the list content depends on the approach used for exposing the clusters (routes, ingress, nodeports or loadbalancers).

When using Kafka with a Kafka cluster not managed by Strimzi, you can specify the bootstrap servers list according to the configuration of the given cluster.

[id='con-common-configuration-ssl-{context}']
== `ssl` (supported TLS versions and cipher suites)

You can incorporate SSL configuration and cipher suite specifications to further secure TLS-based communication between your client application and a Kafka cluster.
In addition to the standard TLS configuration, you can specify a supported TLS version and enable cipher suites in the configuration for the Kafka broker.
You can also add the configuration to your clients if you wish to limit the TLS versions and cipher suites they use. 
The configuration on the client must only use protocols and cipher suites that are enabled on the broker. 

A cipher suite is a set of security mechanisms for secure connection and data transfer.
For example, the cipher suite `TLS_AES_256_GCM_SHA384` is composed of the following mechanisms, which are used in conjunction with the TLS protocol:

* AES (Advanced Encryption Standard) encryption (256-bit key)
* GCM (Galois/Counter Mode) authenticated encryption
* SHA384 (Secure Hash Algorithm) data integrity protection

The combination is encapsulated in the `TLS_AES_256_GCM_SHA384` cipher suite specification.

The `ssl.enabled.protocols` property specifies the available TLS versions that can be used for secure communication between the cluster and its clients. 
The `ssl.protocol` property sets the default TLS version for all connections, and it must be chosen from the enabled protocols.
Use the `ssl.endpoint.identification.algorithm` property to enable or disable hostname verification (configurable only in components based on Kafka clients - Kafka Connect, MirrorMaker 2, and HTTP Bridge).

.Example SSL configuration
[source,yaml,subs="attributes+"]
----
# ...
config:
  ssl.cipher.suites: TLS_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 # <1>
  ssl.enabled.protocols: TLSv1.3, TLSv1.2 # <2>
  ssl.protocol: TLSv1.3 # <3>
  ssl.endpoint.identification.algorithm: HTTPS # <4>
# ...
----
<1> Cipher suite specifications enabled.
<2> TLS versions supported.
<3> Default TLS version is `TLSv1.3`. If