此内容没有您所选择的语言版本。
Using 3scale API Management with the Streams for Apache Kafka Bridge
Use the features and functions available with 3scale
Abstract
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
- Click Create issue.
- In the Summary text box, enter a brief description of the issue.
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.
- Add a reporter name.
- 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=truelabel 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_urifield 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" }{ "instance_id": "consumer1", "base_uri":"http://my-bridge:8080/consumers/my-group/instances/consumer1" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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=httpheader, the Kafka Bridge delivers the following to the consumer.{ "instance_id": "consumer1", "base_uri":"http://my-gateway:80/consumers/my-group/instances/consumer1" }{ "instance_id": "consumer1", "base_uri":"http://my-gateway:80/consumers/my-group/instances/consumer1" }Copy to Clipboard Copied! Toggle word wrap Toggle overflow An
X-Forwarded-Pathheader 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
KafkaBridgecustom 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/consumer1is forwarded to:
http://my-bridge-1-bridge-service:8080/consumers/my-group/instances/consumer1URL 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:
-
OpenAPIcustom resource to import the Kafka Bridge OpenAPI specification -
Productcustom resource to import the Kafka Bridge routing policies and set up an application plan and application. -
ProxyConfigPromotecustom 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.
If 3scale is already deployed in the same cluster as Kafka Bridge, skip the deployment steps and use the existing deployment.
Prerequisites
- Familiarity with 3scale components.
- Streams for Apache Kafka and Kafka are deployed. Refer to the deployment instructions.
- Kafka Bridge is deployed. Refer to the deployment instructions.
For 3scale deployment:
- Check the Red Hat 3scale API Management supported configurations.
-
The installation requires
cluster-adminaccess, such assystem:admin. Access to the following JSON files:
-
Kafka Bridge OpenAPI specification (
openapi.jsonv3). -
Header modification and routing policies for Kafka Bridge (
policies_config.json).
The JSON file is available on GitHub.
-
Kafka Bridge OpenAPI specification (
Procedure
Set up 3scale API Management as outlined in the Red Hat 3scale documentation.
Install 3scale API Manager and APIcast using the 3scale operators.
Before deploying API Manager, update the
wildcardDomainproperty of theAPIManagercustom 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>).-
Verify 3scale deployment by checking the status of the
APIManagercustom resource.
Authorize 3scale API Manager to discover Kafka Bridge:
oc adm policy add-cluster-role-to-user view system:serviceaccount:<my_bridge_namespace>:amp
oc adm policy add-cluster-role-to-user view system:serviceaccount:<my_bridge_namespace>:ampCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command grants the API Manager (
amp) read access (view) to Kafka Bridge resources in the specified namespace (<my_bridge_namespace>).Ensure the Cluster Operator deployment has the required labels and annotations for 3scale discovery:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
/openapiendpoint 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.
- From the 3scale Admin Portal, import the Kafka Bridge API service from OpenShift as outlined in the Red Hat 3scale documentation.
Add the
serversproperty to the OpenAPI specification (JSON file) to reference the base Kafka Bridge service URL:Example reference to the Kafka Bridge service URL
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Make sure the
serversURL includes the following:-
Kafka Bridge name (
my-bridge) -
Project name (
my-project) -
Port for the Kafka Bridge (
8080)
-
Kafka Bridge name (
Import the Kafka Bridge OpenAPI specification by creating an
OpenAPIcustom resource.When creating the
OpenAPIcustom resource, the 3scale operator automatically creates a 3scaleProductcustom resource, which includes a service ID.-
Update the
Productcustom resource by importing the Kafka Bridge routing policies (policies_config.json). - From the 3scale Admin Portal, check that the endpoints and policies for the Kafka Bridge service have loaded.
Update the
Productcustom resource to set up an application plan and application.The application is necessary to obtain a user key for authentication.
-
(For production) Promote the product’s APIcast configuration by creating a
ProxyConfigPromotecustom resource. 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
https//my-project-my-bridge-bridge-service-3scale-apicast-staging.example.com:443/consumers/my-group?user_key=3dfc188650101010ecd7fdc56098ce95Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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" }{ "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 Copied! Toggle word wrap Toggle overflow 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 复制链接链接已复制到粘贴板!
- Go to access.redhat.com.
- If you do not already have an account, create one.
- Log in to your account.
A.2. Activating a Subscription 复制链接链接已复制到粘贴板!
- Go to access.redhat.com.
- Navigate to My Subscriptions.
- 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.
- Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
- Locate the Streams for Apache Kafka entries in the INTEGRATION AND AUTOMATION category.
- Select the desired Streams for Apache Kafka product. The Software Downloads page opens.
- 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>
dnf install <package_name>
To install a previously-downloaded package from a local directory, use:
dnf install <path_to_download_package>
dnf install <path_to_download_package>
Revised on 2025-12-16 10:58:20 UTC