此内容没有您所选择的语言版本。

Using 3scale API Management with the Streams for Apache Kafka Bridge


Red Hat Streams for Apache Kafka 3.1

Use the features and functions available with 3scale

Abstract

Deploy and integrate Red Hat 3scale API Management with a deployment of Streams for Apache Kafka Bridge on OpenShift Container Platform.

Providing feedback on Red Hat documentation

We appreciate your feedback on our documentation.

To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to enable us to address your request quickly.

Prerequisite

  • You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one.

Procedure

  1. Click Create issue.
  2. In the Summary text box, enter a brief description of the issue.
  3. In the Description text box, provide the following information:

    • The URL of the page where you found the issue.
    • A detailed description of the issue.
      You can leave the information in any other fields at their default values.
  4. Add a reporter name.
  5. Click Create to submit the Jira issue to the documentation team.

Thank you for taking the time to provide feedback.

Chapter 1. 3scale API management

If you deployed the Kafka Bridge on OpenShift Container Platform, you can use it with 3scale.

With a plain deployment of the Kafka Bridge, there is no provision for authentication or authorization, and no support for a TLS encrypted connection to external clients. 3scale API Management can secure the Kafka Bridge with TLS, and provide authentication and authorization. Integration with 3scale also means that additional features like metrics, rate limiting, and billing are available.

With 3scale, you can use different types of authentication for requests from external clients wishing to access Streams for Apache Kafka. 3scale supports the following types of authentication:

Standard API Keys
Single randomized strings or hashes acting as an identifier and a secret token.
Application Identifier and Key pairs
Immutable identifier and mutable secret key strings.
OpenID Connect
Protocol for delegated authentication.

1.1. Kafka Bridge service discovery

3scale is integrated using service discovery, which requires that 3scale is deployed to the same OpenShift cluster as Streams for Apache Kafka and the Kafka Bridge.

Your Streams for Apache Kafka Cluster Operator deployment must have the following environment variables set:

  • STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_LABELS
  • STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_ANNOTATIONS

When the Kafka Bridge is deployed, the service that exposes the REST interface of the Kafka Bridge uses the annotations and labels for discovery by 3scale.

  • A discovery.3scale.net=true label is used by 3scale to find a service.
  • Annotations provide information about the service.

You can check your configuration in the OpenShift console by navigating to Services for the Kafka Bridge instance. Under Annotations you will see the endpoint to the OpenAPI specification for the Kafka Bridge.

1.2. 3scale APIcast gateway policies

3scale is used in conjunction with 3scale APIcast, an API gateway deployed with 3scale that provides a single point of entry for the Kafka Bridge.

APIcast policies provide a mechanism to customize how the gateway operates. 3scale provides a set of standard policies for gateway configuration. You can also create your own policies.

For more information on APIcast policies, see the Red Hat 3scale documentation.

APIcast policies for the Kafka Bridge

A sample policy configuration for 3scale integration with the Kafka Bridge is provided with the policies_config.json file, which defines:

  • Anonymous access
  • Header modification
  • Routing
  • URL rewriting

Gateway policies are enabled or disabled through this file.

You can use this sample as a starting point for defining your own policies.

Anonymous access
The anonymous access policy exposes a service without authentication, providing default credentials (for anonymous access) when a HTTP client does not provide them. The policy is not mandatory and can be disabled or removed if authentication is always needed.
Header modification

The header modification policy allows existing HTTP headers to be modified, or new headers added to requests or responses passing through the gateway. For 3scale integration, the policy adds headers to every request passing through the gateway from a HTTP client to the Kafka Bridge.

When the Kafka Bridge receives a request for creating a new consumer, it returns a JSON payload containing a base_uri field with the URI that the consumer must use for all the subsequent requests. For example:

{
  "instance_id": "consumer1",
  "base_uri":"http://my-bridge:8080/consumers/my-group/instances/consumer1"
}
Copy to Clipboard Toggle word wrap

When using APIcast, clients send all subsequent requests to the gateway and not to the Kafka Bridge directly. So the URI requires the gateway hostname, not the address of the Kafka Bridge behind the gateway.

Using header modification policies, headers are added to requests from the HTTP client so that the Kafka Bridge uses the gateway hostname.

For example, by applying a Forwarded: host=my-gateway:80;proto=http header, the Kafka Bridge delivers the following to the consumer.

{
    "instance_id": "consumer1",
    "base_uri":"http://my-gateway:80/consumers/my-group/instances/consumer1"
}
Copy to Clipboard Toggle word wrap

An X-Forwarded-Path header carries the original path contained in a request from the client to the gateway. This header is strictly related to the routing policy applied when a gateway supports more than one Kafka Bridge instance.

Routing

A routing policy is applied when there is more than one Kafka Bridge instance. Requests must be sent to the same Kafka Bridge instance where the consumer was initially created, so a request must specify a route for the gateway to forward a request to the appropriate Kafka Bridge instance.

A routing policy names each bridge instance, and routing is performed using the name. You specify the name in the KafkaBridge custom resource when you deploy the Kafka Bridge.

For example, each request (using X-Forwarded-Path) from a consumer to:

http://my-gateway:80/my-bridge-1/consumers/my-group/instances/consumer1

is forwarded to:

http://my-bridge-1-bridge-service:8080/consumers/my-group/instances/consumer1

URL rewriting policy removes the bridge name, as it is not used when forwarding the request from the gateway to the Kafka Bridge.

URL rewriting

The URL rewiring policy ensures that a request to a specific Kafka Bridge instance from a client does not contain the bridge name when forwarding the request from the gateway to the Kafka Bridge.

The bridge name is not used in the endpoints exposed by the bridge.

1.3. 3scale APIcast for TLS validation

You can set up APIcast for TLS validation, which requires a self-managed deployment of APIcast using a template. The apicast service is exposed as a route.

You can also apply a TLS policy to the Kafka Bridge API.

1.4. Using an existing 3scale deployment

If you already have 3scale deployed to OpenShift and you wish to use it with the Kafka Bridge, ensure that you have the setup described in Deploying 3scale for the Kafka Bridge.

Chapter 2. Deploying 3scale for the Kafka Bridge

To integrate 3scale with Kafka Bridge, you need to configure the deployment to discover the Kafka Bridge API.

In this scenario, Streams for Apache Kafka, Kafka, Kafka Bridge, and 3scale API Management run in the same OpenShift cluster. 3scale APIcast acts as an NGINX-based API gateway, allowing HTTP clients to connect to the Kafka Bridge API service.

This procedure uses the following 3scale custom resources, managed through the 3scale operator:

  • OpenAPI custom resource to import the Kafka Bridge OpenAPI specification
  • Product custom resource to import the Kafka Bridge routing policies and set up an application plan and application.
  • ProxyConfigPromote custom resource to promote the product’s APIcast configuration.

For details on creating and managing these resources, see the operator instructions in the Red Hat 3scale documentation.

Note

If 3scale is already deployed in the same cluster as Kafka Bridge, skip the deployment steps and use the existing deployment.

Prerequisites

For 3scale deployment:

Procedure

  1. Set up 3scale API Management as outlined in the Red Hat 3scale documentation.

    1. Install 3scale API Manager and APIcast using the 3scale operators.

      Before deploying API Manager, update the wildcardDomain property of the APIManager custom resource to match your OpenShift cluster’s domain.

      The domain is used in the URL to access the 3scale Admin Portal (http[s]://<authentication_token>@3scale-admin.<cluster_domain>).

    2. Verify 3scale deployment by checking the status of the APIManager custom resource.
  2. Authorize 3scale API Manager to discover Kafka Bridge:

    oc adm policy add-cluster-role-to-user view system:serviceaccount:<my_bridge_namespace>:amp
    Copy to Clipboard Toggle word wrap

    This command grants the API Manager (amp) read access (view) to Kafka Bridge resources in the specified namespace (<my_bridge_namespace>).

  3. Ensure the Cluster Operator deployment has the required labels and annotations for 3scale discovery:

    #...
    env:
    - name: STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_LABELS
        value: |
        discovery.3scale.net=true
    - name: STRIMZI_CUSTOM_KAFKA_BRIDGE_SERVICE_ANNOTATIONS
        value: |
        discovery.3scale.net/scheme=http
        discovery.3scale.net/port=8080
        discovery.3scale.net/path=/
        discovery.3scale.net/description-path=/openapi
    #...
    Copy to Clipboard Toggle word wrap

    The /openapi endpoint returns the OpenAPI v3 definition of the Kafka Bridge REST API.

    If necessary, update these properties through the OpenShift console or redeploy the Cluster Operator and Kafka Bridge.

  4. From the 3scale Admin Portal, import the Kafka Bridge API service from OpenShift as outlined in the Red Hat 3scale documentation.
  5. Add the servers property to the OpenAPI specification (JSON file) to reference the base Kafka Bridge service URL:

    Example reference to the Kafka Bridge service URL

    {
        "openapi": "3.0.0",
        "info": {
          "title": "Kafka Bridge API Reference",
          "description": "The Kafka Bridge provides a REST API
            for integrating HTTP based client applications with
            a Kafka cluster. You can use the API to create and
            manage consumers and send and receive records over
            HTTP rather than the native Kafka protocol. ",
            "version": "0.1.0"
        },
        "servers": [
          {
            "url": "https://my-bridge-bridge-service.my-project.svc.cluster.local:8080"
          }
        ],
        "paths": {
    Copy to Clipboard Toggle word wrap

    Make sure the servers URL includes the following:

    • Kafka Bridge name (my-bridge)
    • Project name (my-project)
    • Port for the Kafka Bridge (8080)
  6. Import the Kafka Bridge OpenAPI specification by creating an OpenAPI custom resource.

    When creating the OpenAPI custom resource, the 3scale operator automatically creates a 3scale Product custom resource, which includes a service ID.

  7. Update the Product custom resource by importing the Kafka Bridge routing policies (policies_config.json).
  8. From the 3scale Admin Portal, check that the endpoints and policies for the Kafka Bridge service have loaded.
  9. Update the Product custom resource to set up an application plan and application.

    The application is necessary to obtain a user key for authentication.

  10. (For production) Promote the product’s APIcast configuration by creating a ProxyConfigPromote custom resource.
  11. Verify API access to Kafka Bridge through the APIcast gateway using a consumer creation call and the user key generated for the application.

    For example:

    https//my-project-my-bridge-bridge-service-3scale-apicast-staging.example.com:443/consumers/my-group?user_key=3dfc188650101010ecd7fdc56098ce95
    Copy to Clipboard Toggle word wrap

    If the response payload is returned from Kafka Bridge, the consumer was successfully created.

    {
      "instance_id": "consumer1",
      "base uri": "https//my-project-my-bridge-bridge-service-3scale-apicast-staging.example.com:443/consumers/my-group/instances/consumer1"
    }
    Copy to Clipboard Toggle word wrap

    The base URI is the address that the client will use for subsequent requests.

Appendix A. Using your subscription

Streams for Apache Kafka is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.

A.1. Accessing Your Account

  1. Go to access.redhat.com.
  2. If you do not already have an account, create one.
  3. Log in to your account.

A.2. Activating a Subscription

  1. Go to access.redhat.com.
  2. Navigate to My Subscriptions.
  3. Navigate to Activate a subscription and enter your 16-digit activation number.

A.3. Downloading Zip and Tar Files

To access zip or tar files, use the customer portal to find the relevant files for download. If you are using RPM packages, this step is not required.

  1. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
  2. Locate the Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category.
  3. Select the desired Streams for Apache Kafka product. The Software Downloads page opens.
  4. Click the Download link for your component.

A.4. Installing packages with DNF

To install a package and all the package dependencies, use:

dnf install <package_name>
Copy to Clipboard Toggle word wrap

To install a previously-downloaded package from a local directory, use:

dnf install <path_to_download_package>
Copy to Clipboard Toggle word wrap

Revised on 2025-12-16 10:58:20 UTC

Legal Notice

Copyright © Red Hat.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部