redpanda-data · paulohtb6 · Aug 14, 2025 · Aug 7, 2025 · Aug 7, 2025 · Aug 7, 2025
@@ -192,7 +192,7 @@ endpoint to protect credentials in flight.
 
 === Configure the seed servers
 
-Seed servers help new brokers join a cluster by directing requests from newly-started brokers to an existing cluster. The xref:reference:node-properties.adoc#seed_servers[seed_servers] broker configuration property controls how Redpanda finds its peers when initially forming a cluster. It is dependent on the xref:reference:node-properties.adoc#empty_seed_starts_cluster[empty_seed_starts_cluster] broker configuration property.
+Seed servers help new brokers join a cluster by directing requests from newly-started brokers to an existing cluster. The xref:reference:properties/broker-properties.adoc#seed_servers[`seed_servers`] broker property controls how Redpanda finds its peers when initially forming a cluster. It is dependent on the xref:reference:properties/broker-properties.adoc#empty_seed_starts_cluster[`empty_seed_starts_cluster`] broker property.
 
 Starting with Redpanda version 22.3, you should explicitly set `empty_seed_starts_cluster` to `false` on every broker, and every broker in the cluster should have the same value set for `seed_servers`. With this set of configurations, Redpanda clusters form with these guidelines:
 

@@ -402,7 +402,7 @@ LATENCY     P50     P90     P99     P999    MAX
 [[hostnames-interfaces]]
 === Advertised hostnames use correct interfaces
 
-Check that the advertised hostnames are operating on the correct network interfaces. For clusters with multiple interfaces (for example, a public and private IP address), set `advertised_kafka_api` to the public interface and set `advertised_rpc_api` to the private interface. These should be hostnames, not IP addresses.
+Check that the advertised hostnames are operating on the correct network interfaces. For clusters with multiple interfaces (for example, a public and private IP address), set xref:reference:properties/broker-properties.adoc#advertised_kafka_api[`advertised_kafka_api`] to the public interface and set xref:reference:properties/broker-properties.adoc#advertised_rpc_api[`advertised_rpc_api`] to the private interface. These should be hostnames, not IP addresses.
 
 .Example
 [source,bash]

@@ -195,7 +195,7 @@ NodeJS::
 axios
   .get(`${base_uri}/topics`)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application. If your file name is `index.js` for example, you would run the following command:
@@ -290,7 +290,7 @@ let options = { headers: { "Content-Type" : "application/vnd.kafka.json.v2+json"
 axios
   .post(`${base_uri}/topics/test_topic`, payload, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -362,7 +362,7 @@ let options = {
 axios
   .get(`${base_uri}/topics/test_topic/partitions/0/records`, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -442,7 +442,7 @@ let options = { headers: { "Content-Type": "application/vnd.kafka.v2+json" }};
 axios
   .post(`${base_uri}/consumers/test_group`, payload, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -522,7 +522,7 @@ let options = { headers: { "Content-Type": "application/vnd.kafka.v2+json" }};
 axios
   .post(`${base_uri}/consumers/test_group/instances/test_consumer/subscription`, payload, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -582,7 +582,7 @@ let options = {
 axios
   .get(`${base_uri}/consumers/test_group/instances/test_consumer/records`, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -732,7 +732,7 @@ let payload = { partitions: [
 axios
   .post(`${base_uri}/consumers/test_group/instances/test_consumer/offsets`, payload, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 Run the application:
@@ -783,7 +783,7 @@ NodeJS::
 axios
   .get(`${base_uri}/brokers`)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 --
@@ -834,7 +834,7 @@ let options = { headers: { "Content-Type": "application/vnd.kafka.v2+json" }};
 axios
   .delete(`${base_uri}/consumers/test_group/instances/test_consumer`, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 --
@@ -853,7 +853,11 @@ res = requests.delete(
 
 == Authenticate with HTTP Proxy
 
-If the Redpanda HTTP Proxy is configured to use SASL, you can provide the SCRAM username and password as part of the Basic Authentication header in your request. For example, to list topics as an authenticated user:
+HTTP Proxy supports authentication using SCRAM credentials or OIDC tokens. The authentication method depends on the xref:reference:properties/broker-properties.adoc#http_proxy_auth_method[`authentication_method`] broker property configuration and the cluster's xref:reference:properties/cluster-properties.adoc#http_authentication[`http_authentication`] settings.
+
+=== SCRAM Authentication
+
+If HTTP Proxy is configured to support SASL, you can provide the SCRAM username and password as part of the Basic Authentication header in your request. For example, to list topics as an authenticated user:
 
 [tabs]
 =====
@@ -878,7 +882,7 @@ let options = {
 axios
   .get(`${base_uri}/topics`, options)
   .then(response => console.log(response.data))
-  .catch(error => console.log);
+  .catch(error => console.error(error));
 ----
 
 --
@@ -895,6 +899,52 @@ pretty(res)
 --
 =====
 
+=== OIDC Authentication
+
+If HTTP Proxy is configured to support OIDC, you can provide an OIDC token in the Authorization header. For example:
+
+[tabs]
+=====
+curl::
++
+--
+[,bash]
+----
+curl -s -H "Authorization: Bearer <oidc-token>" "<host-address>:8082/topics"
+----
+
+--
+NodeJS::
++
+--
+[,javascript]
+----
+let options = {
+  headers: { Authorization: `Bearer <oidc-token>` },
+};
+
+axios
+  .get(`${base_uri}/topics`, options)
+  .then(response => console.log(response.data))
+  .catch(error => console.error(error));
+----
+
+--
+Python::
++
+--
+[,python]
+----
+headers = {"Authorization": "Bearer <oidc-token>"}
+res = requests.get(f"{base_uri}/topics", headers=headers).json()
+pretty(res)
+----
+
+--
+=====
+
+For details about configuring OIDC authentication, see xref:manage:security/authentication.adoc#oidc-http[OIDC Authentication].
+
 == Use Swagger with HTTP Proxy
 
 You can use Swagger UI to test and interact with Redpanda HTTP Proxy endpoints.
@@ -919,4 +969,4 @@ Verify that the Docker container has been added and is running:
 
 In a browser, enter `<host-address>` in the address bar to open the Swagger console.
 
-Change the URL to `http://<host-address>:8082/v1`, and click `Explore` to update the page with Redpanda HTTP Proxy endpoints. You can call the endpoints in any application and language that supports web interactions. The following examples show how to call the endpoints using curl, NodeJS, and Python.
+Change the URL to `http://<host-address>:8082/v1`, and click `Explore` to update the page with Redpanda HTTP Proxy endpoints. You can call the endpoints in any application and language that supports web interactions. The following examples show how to call the endpoints using curl, NodeJS, and Python.
@@ -47,12 +47,7 @@ The `confluent-kafka-javascript` client is now validated with Redpanda. For a li
 
 == HTTP Proxy authentication changes
 
-[IMPORTANT]
-====
 include::shared:partial$http-proxy-ephemeral-credentials-breaking-change.adoc[tags=!*;include-config-link]
-====
-
-HTTP Proxy previously used automatically-generated ephemeral credentials to authenticate with the Kafka API when the HTTP Proxy listeners specified `authentication_method: none`. To improve security and simplify the authentication model, ephemeral credentials are no longer available.
 
 If you need to maintain the current HTTP Proxy functionality while transitioning to authenticated clients, configure the following HTTP Proxy client properties in your `redpanda.yaml` configuration:
 

@@ -3,7 +3,7 @@
 :page-aliases: cluster-administration:node-property-configuration.adoc, deploy:deployment-option/self-hosted/manual/node-property-configuration.adoc
 :page-categories: Management
 
-When you install Redpanda, a `redpanda.yaml` file is installed on each broker in `/etc/redpanda`. This file contains broker configuration properties. A broker property is one that can be set differently from broker to broker, such as `data_directory` or `node_id` (when specified). See xref:reference:node-properties.adoc[Broker Configuration Properties] for a list of broker properties, their descriptions, and their default values.
+When you install Redpanda, a `redpanda.yaml` file is installed on each broker in `/etc/redpanda`. This file contains broker configuration properties. A broker property is one that can be set differently from broker to broker, such as xref:reference:properties/broker-properties.adoc#data_directory[`data_directory`] or xref:reference:properties/broker-properties.adoc#node_id[`node_id`] (when specified). See xref:reference:properties/broker-properties.adoc[Broker Configuration Properties] for a list of broker properties, their descriptions, and their default values.
 
 The default `redpanda.yaml` file groups broker properties into categories:
 

@@ -40,7 +40,7 @@ rack: "A"
 . Log in to the remaining brokers and edit their `redpanda.yaml` files. For broker 2, set `rack` to `A`. For brokers 3 and 4, set `rack` to `B`. For brokers 5 and 6, set `rack` to `C`.
 . Restart each broker in the cluster for the rack assignments to take effect.
 
-TIP: For high availability, Redpanda recommends adding one or more brokers from each zone to the `seed_servers` configuration.
+TIP: For high availability, Redpanda recommends adding one or more brokers from each zone to the xref:reference:properties/broker-properties.adoc#seed_servers[`seed_servers`] configuration.
 
 [NOTE]
 ====

@@ -421,9 +421,9 @@ redpanda:
 [NOTE]
 ====
 * Remember to replace placeholders in brackets.
-* `kafka_api` is the listener declaration. This `name` can have any value.
-* `advertised_kafka_api` is the advertised listener. This `name` should match the name of a declared listener. This `address` is the host name clients use to connect to the broker.
-* `kafka_api_tls` is the listener's TLS configuration. This `name` must match the corresponding listener's name.
+* xref:reference:properties/broker-properties.adoc#kafka_api[`kafka_api`] is the listener declaration. This `name` can have any value.
+* xref:reference:properties/broker-properties.adoc#advertised_kafka_api[`advertised_kafka_api`] is the advertised listener. This `name` should match the name of a declared listener. This `address` is the host name clients use to connect to the broker.
+* xref:reference:properties/broker-properties.adoc#kafka_api_tls[`kafka_api_tls`] is the listener's TLS configuration. This `name` must match the corresponding listener's name.
 ====
 
 See also: xref:./listener-configuration.adoc[Configure Listeners]

@@ -51,7 +51,9 @@ redpanda:
 
 == Multiple listeners
 
-You can define multiple Kafka API listeners to support different interfaces, ports, or authentication methods. Each listener must have a unique `name` property, and the same `name` property must be used in the corresponding `advertised_kafka_api` stanza.
+You can define multiple Kafka API listeners to support different interfaces, ports, or authentication methods. Each listener must have a unique `name` property, and the same `name` property must be used in the corresponding xref:reference:properties/broker-properties.adoc#advertised_kafka_api[`advertised_kafka_api`] listener definition.
+
+For details about authentication methods, see the xref:reference:properties/broker-properties.adoc#kafka_api_auth_method[`authentication_method`] broker property.
 
 [source,yaml]
 ----
@@ -77,7 +79,7 @@ redpanda:
 
 == TLS listeners and DNS hostnames
 
-For encrypted connections, you typically advertise a DNS name matching your TLS certificate. Always include a `name` property for the TLS listener and use it in both `kafka_api` and `advertised_kafka_api`.
+For encrypted connections, you typically advertise a DNS name matching your TLS certificate. Always include a `name` property for the TLS listener and use it in both xref:reference:properties/broker-properties.adoc#kafka_api[`kafka_api`] and xref:reference:properties/broker-properties.adoc#advertised_kafka_api[`advertised_kafka_api`].
 
 [source,yaml]
 ----
@@ -106,7 +108,7 @@ Ensure `kafka.example.com` matches the SAN in `broker.crt` and that clients trus
 
 == Mixed-mode authentication with multiple listeners
 
-Redpanda supports running multiple authentication schemes concurrently. Each listener can specify its method, and must define a `name` property.
+Redpanda supports running multiple authentication schemes concurrently. Each listener can specify its xref:reference:properties/broker-properties.adoc#kafka_api_auth_method[`authentication_method`], and must define a `name` property.
 
 [source,yaml]
 ----