docs(oauth): updates oauth config references (#12141)

PaulRMellor · web-flow · commit e59f6a22513a · 2025-11-25T16:53:38.000+01:00
Signed-off-by: prmellor &lt;pmellor@redhat.com&gt;
diff --git a/documentation/assemblies/oauth/assembly-oauth-security.adoc b/documentation/assemblies/oauth/assembly-oauth-security.adoc
@@ -13,6 +13,10 @@ Scopes correspond to different levels of access to Kafka topics or operations wi
 
 OAuth 2.0 also supports single sign-on and integration with identity providers. 
 
+NOTE: The authentication type `oauth` and `keycloak` authorization type are deprecated and will be removed in a future release. 
+Use the `custom` authentication and authorization type to configure token-based security on listeners and components.
+This content is currently being updated to reflect the transition to the `custom` authentication type.
+
 ifdef::Section[]
 For more information on using OAuth 2.0, see the link:https://github.com/strimzi/strimzi-kafka-oauth[Strimzi OAuth 2.0 for Apache Kafka project^].
 endif::Section[]
diff --git a/documentation/modules/configuring/con-config-examples.adoc b/documentation/modules/configuring/con-config-examples.adoc
@@ -42,7 +42,9 @@ examples
 --
 <1> `KafkaUser` custom resource configuration, which is managed by the User Operator.
 <2> `KafkaTopic` custom resource configuration, which is managed by Topic Operator.
-<3> Authentication and authorization configuration for Kafka components. Includes example configuration for TLS and SCRAM-SHA-512 authentication. The Keycloak example includes `Kafka` custom resource configuration and a Keycloak realm specification. You can use the example to try Keycloak authorization services. There is also an example with enabled `oauth` authentication and `keycloak` authorization metrics.
+<3> Authentication and authorization configuration for Kafka components. 
+Includes example configuration for TLS and SCRAM-SHA-512 authentication. 
+The Keycloak examples include a Keycloak realm specification and two `Kafka` custom resources with `type: custom` definitions for using OAuth 2.0 authentication and Keycloak authorization with or without metrics enabled.
 <4> `KafkaMirrorMaker2` custom resource configurations for a deployment of MirrorMaker 2. Includes example configuration for replication policy and synchronization frequency.
 <5> xref:assembly-metrics-config-files-{context}[Metrics configuration], including Prometheus installation and Grafana dashboard files.
 <6> `Kafka` and `KafkaNodePool` custom resource configurations for a deployment of Kafka clusters that use KRaft mode. Includes example configuration for an ephemeral or persistent single or multi-node deployment.
diff --git a/documentation/modules/configuring/con-config-http-bridge.adoc b/documentation/modules/configuring/con-config-http-bridge.adoc
@@ -125,7 +125,7 @@ spec:
 <4> CORS access specifying selected resources and access methods. Additional HTTP headers in requests describe the origins that are permitted access to the Kafka cluster.
 <5> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
 <6> TLS configuration for encrypted connections to the Kafka cluster, with trusted certificates stored in X.509 format within the specified secrets.
-<7> Authentication for the HTTP Bridge cluster, specified as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`.
+<7> Authentication for the HTTP Bridge cluster, specified as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`.
 By default, the HTTP Bridge connects to Kafka brokers without authentication.
 For details on configuring authentication, see the link:{BookURLConfiguring}#type-KafkaBridgeSpec-schema-reference[`KafkaBridgeSpec` schema properties^]
 <8> Consumer configuration options.
diff --git a/documentation/modules/configuring/con-config-kafka-connect.adoc b/documentation/modules/configuring/con-config-kafka-connect.adoc
@@ -175,7 +175,7 @@ In this example, JSON convertors are specified.
 A replication factor of 3 is set for the internal topics used by Kafka Connect (minimum requirement for production environment).
 Changing the replication factor after the topics have been created has no effect.
 <10> Requests for reservation of supported resources, currently `cpu` and `memory`, and limits to specify the maximum resources that can be consumed.
-<11> Authentication for the Kafka Connect cluster, specified as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`.
+<11> Authentication for the Kafka Connect cluster, specified as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`.
 By default, Kafka Connect connects to Kafka brokers using a plaintext connection.
 For details on configuring authentication, see the link:{BookURLConfiguring}#type-KafkaConnectSpec-schema-reference[`KafkaConnectSpec` schema properties^].
 <12> TLS configuration for encrypted connections to the Kafka cluster, with trusted certificates stored in X.509 format within the specified secrets.
diff --git a/documentation/modules/configuring/con-config-kafka-kraft.adoc b/documentation/modules/configuring/con-config-kafka-kraft.adoc
@@ -157,7 +157,7 @@ spec:
 <4> Listener type specified as `internal` or `cluster-ip` (to expose Kafka using per-broker `ClusterIP` services), or for external listeners, as `route` (OpenShift only), `loadbalancer`, `nodeport` or `ingress` (Kubernetes only).
 <5> Enables or disables TLS encryption for each listener. For `route` and `ingress` type listeners, TLS encryption must always be enabled by setting it to `true`.
 <6> Defines whether the fully-qualified DNS names including the cluster service suffix (usually `.cluster.local`) are assigned.
-<7> Listener authentication mechanism specified as mTLS, SCRAM-SHA-512, or token-based OAuth 2.0.
+<7> Listener authentication mechanism specified as mTLS, SCRAM-SHA-512, or custom.
 <8> External listener configuration specifies how the Kafka cluster is exposed outside Kubernetes, such as through a `route`, `loadbalancer` or `nodeport`.
 <9> Optional configuration for a Kafka listener certificate managed by an external CA (certificate authority). The `brokerCertChainAndKey` specifies a `Secret` that contains a server certificate and a private key. You can configure Kafka listener certificates on any listener with enabled TLS encryption.
 <10> Kafka version, which can be changed to a supported version by following the upgrade procedure.
@@ -167,7 +167,7 @@ spec:
 <14> Healthchecks to know when to restart a container (liveness) and when a container can accept traffic (readiness).
 <15> JVM configuration options to optimize performance for the Virtual Machine (VM) running Kafka.
 <16> ADVANCED OPTION: Container image configuration, which is recommended only in special situations.
-<17> Authorization enables simple, OAuth 2.0, custom, or OPA (deprecated) authorization on the Kafka broker. Simple authorization uses the `StandardAuthorizer` Kafka plugin.
+<17> Authorization enables simple and custom authorization on the Kafka broker. Simple authorization uses the `StandardAuthorizer` Kafka plugin.
 <18> Rack awareness configuration to spread replicas across different racks, data centers, or availability zones. The `topologyKey` must match a node label containing the rack ID. The example used in this configuration specifies a zone using the standard `{K8sZoneLabel}` label.
 Use rack awareness together with custom `topologySpreadConstraint` or `affinity` rules to distribute Kafka broker pods (replicas) across zones.
 <19> Prometheus metrics enabled. In this example, metrics are configured for the Prometheus JMX Exporter (the default metrics exporter).
diff --git a/documentation/modules/configuring/proc-config-mirrormaker2-securing-connection.adoc b/documentation/modules/configuring/proc-config-mirrormaker2-securing-connection.adoc
@@ -344,6 +344,6 @@ spec:
 <1> The TLS certificates for the target Kafka cluster.
 <2> The user authentication for accessing the target Kafka cluster.
 <3> The TLS certificates for the source Kafka cluster. If they are in a separate namespace, copy the cluster secrets from the namespace of the Kafka cluster.
-<4> The user authentication for accessing the source Kafka cluster using the TLS mechanism. Supported authentication methods include `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, and `oauth`.
+<4> The user authentication for accessing the source Kafka cluster using the TLS mechanism. Supported authentication methods include `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, and `custom`.
 
 . Apply the changes to the `KafkaMirrorMaker2` resource to the same namespace as the target Kafka cluster.
diff --git a/documentation/modules/deploying/proc-deploy-http-bridge.adoc b/documentation/modules/deploying/proc-deploy-http-bridge.adoc
@@ -31,11 +31,9 @@ This procedure assumes that the Kafka cluster was deployed using Strimzi.
 In `examples/bridge/kafka-bridge.yaml`, add or update the following properties as needed: 
 +
 * `spec.bootstrapServers` to specify the Kafka bootstrap address.
-* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`. +
-See the link:{BookURLConfiguring}#type-KafkaBridgeSpec-schema-reference[`KafkaBridgeSpec` schema properties^] for configuration details.
+* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`. See the link:{BookURLConfiguring}#type-KafkaBridgeSpec-schema-reference[`KafkaBridgeSpec` schema properties^] for configuration details.
 * `spec.tls.trustedCertificates` to configure the TLS certificate. +
-Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. +
-See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
+Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
 
 . Deploy HTTP Bridge to your Kubernetes cluster:
 +
diff --git a/documentation/modules/deploying/proc-deploy-kafka-connect.adoc b/documentation/modules/deploying/proc-deploy-kafka-connect.adoc
@@ -37,11 +37,9 @@ This procedure assumes that the Kafka cluster was deployed using Strimzi.
 In `examples/connect/kafka-connect.yaml`, add or update the following properties as needed: 
 +
 * `spec.bootstrapServers` to specify the Kafka bootstrap address.
-* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`. +
-See the link:{BookURLConfiguring}#type-KafkaConnectSpec-schema-reference[`KafkaConnectSpec` schema properties^] for configuration details.
+* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`. See the link:{BookURLConfiguring}#type-KafkaConnectSpec-schema-reference[`KafkaConnectSpec` schema properties^] for configuration details.
 * `spec.tls.trustedCertificates` to configure the TLS certificate. +
-Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. +
-See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
+Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
 
 . Configure the deployment for multiple Kafka Connect clusters (if required).
 + 
diff --git a/documentation/modules/deploying/proc-deploy-kafka-mirror-maker.adoc b/documentation/modules/deploying/proc-deploy-kafka-mirror-maker.adoc
@@ -36,7 +36,7 @@ In `examples/mirror-maker/kafka-mirror-maker-2.yaml`, add or update the followin
 +
 * `spec.target.bootstrapServers` and `.spec.mirrors[].source.bootstrapServers` to specify the Kafka bootstrap address for the source and target clusters.
 * `spec.target.alias` and `.spec.mirrors[].source.alias` to specify a unique identifier for each cluster.
-* `spec.target.authentication` and `.spec.mirrors[].source.authentication` to specify the authentication type for each cluster as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`.
+* `spec.target.authentication` and `.spec.mirrors[].source.authentication` to specify the authentication type for each cluster as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`.
 See the link:{BookURLConfiguring}#type-KafkaMirrorMaker2ClusterSpec-schema-reference[`KafkaMirrorMaker2Spec` schema properties^] for configuration details.
 * `spec.target.tls.trustedCertificates` and `.spec.mirrors[].source.tls.trustedCertificates` to configure the TLS certificate for each cluster.
 Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates.
diff --git a/documentation/modules/deploying/proc-deploy-setup-external-clients.adoc b/documentation/modules/deploying/proc-deploy-setup-external-clients.adoc
@@ -23,10 +23,10 @@ Client access to the Kafka cluster is secured with the following configuration:
 
 At least one listener supporting the desired authentication must be configured for the `KafkaUser`.
 
-Listeners can be configured for mutual `TLS`, `SCRAM-SHA-512`, or `OAuth` authentication. 
-While mTLS always uses encryption, it's also recommended when using SCRAM-SHA-512 and OAuth 2.0 authentication.
+Listeners can be configured for mutual `TLS`, `SCRAM-SHA-512`, or `custom` authentication. 
+While mTLS always uses encryption, it's also recommended when using SCRAM-SHA-512 or a custom configuration for OAuth 2.0 authentication.
 
-Authorization options for Kafka include `simple`, `OAuth`, `OPA`, or `custom`. 
+Authorization options for Kafka include `simple` or `custom`. 
 When enabled, authorization is applied to all enabled listeners.
 
 To ensure compatibility between Kafka and clients, configuration of the following authentication and authorization mechanisms must align:
diff --git a/documentation/modules/metrics/proc-jmx-exporter-metrics-kafka-deploy-options.adoc b/documentation/modules/metrics/proc-jmx-exporter-metrics-kafka-deploy-options.adoc
@@ -10,24 +10,18 @@
 [role="_abstract"]
 To enable and expose metrics in Strimzi for Prometheus, configure the appropriate properties in the custom resources for the components you want to monitor.
 
-Use `metricsConfig` to expose metrics for these components:
+Use `metricsConfig` to expose JMX-based metrics for these components:
 
 * Kafka
 * Kafka Connect
 * Kafka MirrorMaker 2
 * HTTP Bridge
 * Cruise Control
 
-This enables the {JMXExporter}, which exposes metrics on port 9404 through an HTTP endpoint. 
+The {JMXExporter} exposes metrics on port 9404 through an HTTP endpoint. 
 Prometheus scrapes this endpoint to collect Kafka metrics.
 
-Set `enableMetrics` to `true` to expose metrics for the following:
-
-* OAuth 2.0
-** Configure in the `Kafka` resource for `oauth` or `keycloak` cluster authorization, or `oauth` listener authentication.
-** Configure in the `KafkaBridge`, `KafkaConnect`, or `KafkaMirrorMaker2` resources for `oauth` authentication.
-
-You can create your own Prometheus configuration or use the xref:assembly-metrics-config-files-{context}[example custom resource files] provided with Strimzi:
+You can create your own Prometheus configuration or start with the xref:assembly-metrics-config-files-{context}[example custom resource files] provided with Strimzi:
 
 * `kafka-metrics.yaml`
 * `kafka-connect-metrics.yaml`
@@ -38,32 +32,32 @@ You can create your own Prometheus configuration or use the xref:assembly-metric
 
 These files include relabeling rules and example metrics configuration, and are a good starting point for trying Prometheus with Strimzi.
 
-This procedure shows how to deploy example Prometheus metrics configuration to the `Kafka` resource.
+NOTE: OAuth 2.0–related metrics are also available when OAuth 2.0 authentication or authorization is configured by using `type: custom`.  
+For a working example that enables OAuth 2.0 metrics for Kafka, see the `kafka-ephemeral-oauth-single-keycloak-authz-metrics.yaml` example file.
+
+This procedure shows how to deploy the example Prometheus metrics configuration to the `Kafka` resource.
 The same steps apply when deploying the example files for other resources.
 
 .Procedure
 
 . Deploy the example custom resource with the Prometheus configuration.
 +
-For example, for each `Kafka` resource you can apply the `kafka-metrics.yaml` file.
+For example, for each `Kafka` resource you can apply the `kafka-metrics.yaml` file:
 +
-.Deploying the example configuration
 [source,shell,subs="+attributes"]
 ----
 kubectl apply -f kafka-metrics.yaml
 ----
 +
-Alternatively, copy the example configuration in `kafka-metrics.yaml` to your own `Kafka` resource.
+Alternatively, copy the example configuration in `kafka-metrics.yaml` to your own `Kafka` resource:
 +
-.Copying the example configuration
 [source,shell]
 ----
 kubectl edit kafka <kafka_configuration_file>
 ----
 +
-Copy the `metricsConfig` property and the `ConfigMap` it references to your `Kafka` resource.
+Add the `metricsConfig` property and corresponding `ConfigMap` as shown in the following example:
 +
-.Example metrics configuration for Kafka
 [source,yaml,subs="+quotes,attributes"]
 ----
 apiVersion: {KafkaApiVersion}
@@ -90,51 +84,7 @@ data:
   kafka-metrics-config.yml: |
   # _metrics configuration..._
 ----
-<1> Copy the `metricsConfig` property that references the `ConfigMap` containing metrics configuration.
-<2> Copy the whole `ConfigMap` specifying the metrics configuration.
-
-.Enabling metrics for OAuth 2.0 
-
-To expose metrics for OAuth 2.0, set the `enableMetrics` property to `true` in the appropriate custom resource.
-
-* In the Kafka resource for:
-** Cluster authorization (`oauth` or `keycloak`)
-** Listener authentication (`oauth` only)
-* In the `KafkaBridge`, `KafkaConnect`, or `KafkaMirrorMaker2` resources for `oauth` authentication  
-
-In the following example, metrics are enabled for OAuth 2.0 listener authentication and OAuth 2.0 (`keycloak`) cluster authorization.
-
-.Example configuration with OAuth 2.0 metrics enabled
-[source,yaml,subs="+quotes,attributes"]
-----
-apiVersion: {KafkaApiVersion}
-kind: Kafka
-metadata:
-  name: my-cluster
-  namespace: myproject
-spec:
-  kafka:
-    # ...
-    listeners:
-    - name: external3
-      port: 9094
-      type: loadbalancer
-      tls: true
-      authentication:
-        type: oauth
-        enableMetrics: true
-      configuration:
-        #...
-    authorization:
-      type: keycloak
-      enableMetrics: true
-  # ...
-----
-
-To use OAuth 2.0 metrics with Prometheus, copy the `ConfigMap` configuration from the `oauth-metrics.yaml` file to the same `Kafka` resource configuration file where you enabled metrics for OAuth 2.0 and then apply the configuration.
-
-NOTE: You can also enable metrics for the `type: opa` authorization option in the same way as for OAuth 2.0 authorization.
-However, `type: opa` is deprecated and will be removed in a future release.
-To continue using the Open Policy Agent authorizer, use the `type: custom` authorization configuration.
+<1> Add the `metricsConfig` property that references the metrics `ConfigMap`.
+<2> Add the complete `ConfigMap` definition with the JMX Exporter configuration.
 
 
diff --git a/documentation/modules/security/con-securing-kafka-authentication.adoc b/documentation/modules/security/con-securing-kafka-authentication.adoc
@@ -23,11 +23,10 @@ Supported authentication options:
 
 . mTLS authentication (only on the listeners with TLS enabled encryption)
 . SCRAM-SHA-512 authentication
-. xref:assembly-oauth-authentication_str[OAuth 2.0 token-based authentication]
 . link:{BookURLConfiguring}#type-KafkaListenerAuthenticationCustom-reference[Custom authentication^]
 . link:{BookURLConfiguring}#con-common-configuration-ssl-reference[TLS versions and cipher suites^]
 
-If you're using OAuth 2.0 for client access management, user authentication and authorization credentials are handled through the authorization server.
+Use custom authentication to configure token-based client access management, so that user authentication and authorization credentials are handled through an authorization server.
 
 The authentication option you choose depends on how you wish to authenticate client access to Kafka brokers.
 
diff --git a/documentation/modules/security/con-securing-kafka-authorization.adoc b/documentation/modules/security/con-securing-kafka-authorization.adoc
@@ -16,10 +16,10 @@ The authorization method is defined in the `type` field.
 Supported authorization options:
 
 * link:{BookURLConfiguring}#type-KafkaAuthorizationSimple-reference[Simple authorization]
-* xref:assembly-oauth-authorization_str[OAuth 2.0 authorization] (if you are using OAuth 2.0 token based authentication)
-* link:{BookURLConfiguring}#type-KafkaAuthorizationOpa-reference[Open Policy Agent (OPA) authorization]
 * link:{BookURLConfiguring}#type-KafkaAuthorizationCustom-reference[Custom authorization]
 
+Use custom authorization to configure token-based authorization.
+
 .Kafka cluster authorization options
 image::kafka-authorization-config-options.png[options for kafka authorization configuration]
 
diff --git a/documentation/shared/images/kafka-authorization-config-options.png b/documentation/shared/images/kafka-authorization-config-options.png
diff --git a/documentation/shared/images/listener-config-options.png b/documentation/shared/images/listener-config-options.png

Original file line number	Diff line number	Diff line change
`@@ -31,11 +31,9 @@ This procedure assumes that the Kafka cluster was deployed using Strimzi.`
`31`	`31`	In `examples/bridge/kafka-bridge.yaml`, add or update the following properties as needed:
`32`	`32`	`+`
`33`	`33`	* `spec.bootstrapServers` to specify the Kafka bootstrap address.
`34`		-* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`. +
`35`		-See the link:{BookURLConfiguring}#type-KafkaBridgeSpec-schema-reference[`KafkaBridgeSpec` schema properties^] for configuration details.
	`34`	+* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`. See the link:{BookURLConfiguring}#type-KafkaBridgeSpec-schema-reference[`KafkaBridgeSpec` schema properties^] for configuration details.
`36`	`35`	* `spec.tls.trustedCertificates` to configure the TLS certificate. +
`37`		-Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. +
`38`		-See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
	`36`	+Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
`39`	`37`
`40`	`38`	`. Deploy HTTP Bridge to your Kubernetes cluster:`
`41`	`39`	`+`
Original file line number	Diff line number	Diff line change
`@@ -37,11 +37,9 @@ This procedure assumes that the Kafka cluster was deployed using Strimzi.`
`37`	`37`	In `examples/connect/kafka-connect.yaml`, add or update the following properties as needed:
`38`	`38`	`+`
`39`	`39`	* `spec.bootstrapServers` to specify the Kafka bootstrap address.
`40`		-* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`. +
`41`		-See the link:{BookURLConfiguring}#type-KafkaConnectSpec-schema-reference[`KafkaConnectSpec` schema properties^] for configuration details.
	`40`	+* `spec.authentication` to specify the authentication type as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`. See the link:{BookURLConfiguring}#type-KafkaConnectSpec-schema-reference[`KafkaConnectSpec` schema properties^] for configuration details.
`42`	`41`	* `spec.tls.trustedCertificates` to configure the TLS certificate. +
`43`		-Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. +
`44`		-See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
	`42`	+Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates. See the link:{BookURLConfiguring}#con-common-configuration-trusted-certificates-reference[`trustedCertificates` properties^] for configuration details.
`45`	`43`
`46`	`44`	`. Configure the deployment for multiple Kafka Connect clusters (if required).`
`47`	`45`	`+`
Original file line number	Diff line number	Diff line change
@@ -36,7 +36,7 @@ In `examples/mirror-maker/kafka-mirror-maker-2.yaml`, add or update the followin
`36`	`36`	`+`
`37`	`37`	* `spec.target.bootstrapServers` and `.spec.mirrors[].source.bootstrapServers` to specify the Kafka bootstrap address for the source and target clusters.
`38`	`38`	* `spec.target.alias` and `.spec.mirrors[].source.alias` to specify a unique identifier for each cluster.
`39`		-* `spec.target.authentication` and `.spec.mirrors[].source.authentication` to specify the authentication type for each cluster as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `oauth`.
	`39`	+* `spec.target.authentication` and `.spec.mirrors[].source.authentication` to specify the authentication type for each cluster as `tls`, `scram-sha-256`, `scram-sha-512`, `plain`, or `custom`.
`40`	`40`	See the link:{BookURLConfiguring}#type-KafkaMirrorMaker2ClusterSpec-schema-reference[`KafkaMirrorMaker2Spec` schema properties^] for configuration details.
`41`	`41`	* `spec.target.tls.trustedCertificates` and `.spec.mirrors[].source.tls.trustedCertificates` to configure the TLS certificate for each cluster.
`42`	`42`	Use `[]` (an empty array) to trust the default Java CAs, or specify secrets containing trusted certificates.