Strimzi Kafka Bridge 服务端 TLS 支持验证HttpBridgeServerTlsST 系统测试套件深度解析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读本文聚焦 Strimzi Kafka Operator 仓库中用于验证 Kafka Bridge HTTP 服务端 TLS 能力的系统测试套件HttpBridgeServerTlsST完整梳理其前置部署流程、两个核心测试用例的逐步执行逻辑并结合仓库源码剖析 KafkaBridge 资源中http.tls配置模型的底层实现与字段约束。读完本文你将掌握 Strimzi 如何通过 KafkaUser 生成 Bridge 服务端证书、如何在 KafkaBridge CR 中启用 HTTPS、以及系统测试如何端到端验证「HTTP over TLS 生产/消费」全链路。测试套件定位验证 Kafka Bridge 服务端 TLS在 Strimzi 生态中Kafka Bridge 承担着 HTTP 客户端与 Kafka 集群之间的协议转换角色将 REST API 与 Kafka 消息系统集成起来。当 HTTP 客户端与 Bridge 之间需要加密传输时就必须为 Bridge 的 HTTP 服务端启用 TLS。HttpBridgeServerTlsST正是负责验证这一能力的系统测试套件。该套件定义于源码文件 HttpBridgeServerTlsST.java其官方描述为Test suite for verifying TLS support for HTTP Bridge server.验证 HTTP Bridge 服务器 TLS 支持的测试套件套件级注解SuiteDoc中给出的完整语义如下描述验证 HTTP Bridge 服务器的 TLS 支持。标签Labelsbridge归属于 bridge 测试标签体系同时测试类上还标有Tag(REGRESSION)、Tag(BRIDGE)、Tag(ACCEPTANCE)三个 JUnit 标签分别对应回归、Bridge 组件、验收三类测试分组。与仅验证明文 HTTP 的HttpBridgeST、验证客户端认证的HttpBridgeTlsSTTLS 客户端认证以及 SCRAM-SHA 认证的HttpBridgeScramShaST不同本套件的核心关注点在于Bridge 服务端自己提供 TLS 证书、以 HTTPS 协议对外提供服务测试中的 HTTP 客户端通过信任该服务端证书来建立加密连接。套件级前置步骤四步准备 TLS 运行环境根据套件文档在执行任何测试用例之前必须先完成以下四个前置步骤| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 初始化测试存储与上下文 | 测试存储与上下文初始化成功 | | 2 | 创建 KafkaUser 以生成 HTTP Bridge 服务器证书与密钥 | 用于生成 HTTP Bridge 服务器证书与密钥的 KafkaUser 已创建 | | 3 | 部署配置了 HTTP Bridge 服务器证书与密钥的 Kafka 与 KafkaBridge | Kafka 与 KafkaBridge 已部署并正常运行 | | 4 | 创建 BridgeClients 实例 | BridgeClients 实例已创建 |上述步骤在源码中由BeforeAll修饰的setUp()方法实现其执行流程与文档一一对应并蕴含了 Strimzi 的一个关键设计利用 User Operator 为 TLS 用户签发证书的机制来为 Bridge 服务端生成证书。步骤 1初始化测试存储suiteTestStorage new TestStorage(KubeResourceManager.get().getTestContext());TestStorage是系统测试中统一管理命名空间、集群名、Topic 名、用户名、消息数量等测试数据的存储类见 TestStorage.java。其中消息数量默认值为MESSAGE_COUNT 100见 TestConstants.java意味着每个用例默认验证 100 条消息的端到端传输。随后通过SetupClusterOperator.getInstance().withDefaultConfiguration().install()安装 Cluster Operator含 CRD、ServiceAccount、RBAC 与 Deployment这是所有系统测试的运行前提。步骤 2创建 KafkaUser 生成服务端证书与密钥这是本套件最值得注意的设计点。Strimzi 中 KafkaUser 资源在启用 TLS 客户端认证后User Operator 会为其生成证书与私钥。本套件巧妙地复用了这一能力——让 KafkaUser 的名称与 KafkaBridge 的 Service 名称一致从而让生成的证书以 Bridge Service 名为 CN直接充当 Bridge 的 HTTPS 服务端证书// Create KafkaUser to generate the HTTP Bridge server certificate and key // The KafkaBridge serviceName will be used as the CN for the HTTP Bridge server certificate KafkaUser tlsUser KafkaUserTemplates.tlsUser( Environment.TEST_SUITE_NAMESPACE, KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName()), suiteTestStorage.getClusterName()).build(); KubeResourceManager.get().createResourceWithWait(tlsUser);从模板实现看tlsUser() 构建的 KafkaUser 规格为spec: authentication: type: tls即KafkaUserTlsClientAuthentication类型。该用户创建成功后其凭据 Secret名称与用户名一致即 Bridge Service 名中包含ca.crt、user.crt、user.key等条目其中user.crt/user.key即后续 Bridge HTTPS 使用的服务端证书与密钥。步骤 3部署 Kafka 与启用 TLS 的 KafkaBridge首先部署 Kafka 集群。源码使用 KRaft 模式下的 NodePool 布局分别创建 Broker 与 Controller 两个持久化 NodePool再创建 Kafka 集群KubeResourceManager.get().createResourceWithWait( KafkaNodePoolTemplates.brokerPoolPersistentStorage(namespace, brokerPoolName, clusterName, 1).build(), KafkaNodePoolTemplates.controllerPoolPersistentStorage(namespace, controllerPoolName, clusterName, 1).build()); KubeResourceManager.get().createResourceWithWait(KafkaTemplates.kafka(namespace, clusterName, 1).build());随后部署 KafkaBridge。关键在.editSpec()中对http段的配置KubeResourceManager.get().createResourceWithWait(KafkaBridgeTemplates.kafkaBridge( namespace, clusterName, KafkaResources.plainBootstrapAddress(clusterName), 1) .editSpec() .withNewConsumer() .addToConfig(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, earliest) .endConsumer() .withNewHttp() .withPort(8443) .withNewTls() .withNewCertificateAndKey() .withSecretName(KafkaBridgeResources.serviceName(clusterName)) .withCertificate(user.crt) .withKey(user.key) .endCertificateAndKey() .endTls() .endHttp() .endSpec() .build());对照默认模板KafkaBridgeTemplates.java可以看出默认的kafkaBridge()仅配置bootstrapServers、replicas、DEBUG 级日志与port: 8080的明文 HTTP本用例在此基础上叠加了HTTPS 端口 8443 与服务端证书引用。这里形成的 TLS 配置语义为| 字段 | 取值 | 含义 | | - | - | - | |http.port|8443| HTTPS 监听端口需大于 1023 | |http.tls.certificateAndKey.secretName| Bridge 的 Service 名 | 存放证书与密钥的 Secret 名称即上一步 KafkaUser 的凭据 Secret | |http.tls.certificateAndKey.certificate|user.crt| Secret 中证书文件名 | |http.tls.certificateAndKey.key|user.key| Secret 中私钥文件名 |另外consumer段设置了auto.offset.resetearliest确保后续 HTTP 消费者从最早的 offset 开始消费从而可靠地收到测试消息。步骤 4创建 BridgeClients 实例前置最后一步构建两类客户端构建器供两个测试用例复用kafkaProducerConsumerBuilder new KafkaProducerConsumerBuilder() .withNamespaceName(suiteTestStorage.getNamespaceName()) .withMessageCount(suiteTestStorage.getMessageCount()) .withTopicName(suiteTestStorage.getTopicName()) .withBootstrapAddress(KafkaResources.plainBootstrapAddress(suiteTestStorage.getClusterName())); httpProducerConsumerBuilder new HttpProducerConsumerBuilder() .withHostname(KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName())) .withTopicName(suiteTestStorage.getTopicName()) .withMessageCount(suiteTestStorage.getMessageCount()) .withPort(8443) .withNamespaceName(Environment.TEST_SUITE_NAMESPACE) .withSslTruststoreCertificate(KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName()));值得注意的是httpProducerConsumerBuilder的两个参数withPort(8443)HTTP 客户端必须访问 Bridge 的 HTTPS 端口withSslTruststoreCertificate(serviceName)客户端以 Bridge Service 名为信任源构建 Truststore即信任服务端证书这是 HTTPS 客户端侧建立信任链的关键。测试用例一testSendSimpleMessageTls——HTTPS 生产Kafka 消费验证描述验证使用 TLS 发送简单消息是否正确工作。该用例的业务链路为HTTP Producer →HTTPS 8443→ Kafka Bridge → Kafka Topic → Kafka Consumer即验证消息经 HTTPS 进入 Bridge 后能正确落入 Kafka。文档定义的逐步流程如下| 步骤 | 动作 | 结果 | | - | - | - | | 1 | 初始化 TestStorage 与 BridgeClients | TestStorage 与 BridgeClients 初始化完成 | | 2 | 使用资源管理器创建 Kafka Topic | Kafka Topic 创建成功 | | 3 | 创建带 TLS 配置的 Kafka Bridge Client Job 用于生产消息 | 带 TLS 配置的 Kafka Bridge Client Job 创建成功并生产消息 | | 4 | 验证 producer 成功发送消息 | Producer 成功发送预期数量的消息 | | 5 | 创建 Kafka 客户端用于消费 | Kafka 客户端 consumer 创建完成 | | 6 | 验证 consumer 成功接收消息 | Consumer 成功接收预期数量的消息 |源码实现要点// 为 HTTP producer 放行访问 Bridge 的 NetworkPolicy NetworkPolicyUtils.allowNetworkPolicyForBridgeClient( testStorage.getNamespaceName(), suiteTestStorage.getClusterName(), testStorage.getProducerName()); HttpProducerConsumer bridgeProducerConsumer httpProducerConsumerBuilder .withTopicName(testStorage.getTopicName()) .withProducerName(testStorage.getProducerName()) .build(); // 创建 Topic KubeResourceManager.get().createResourceWithWait( KafkaTopicTemplates.topic(namespace, topicName, clusterName).build()); // 部署 HTTP producer JobHTTPS 访问 Bridge 8443 KubeResourceManager.get().createResourceWithWait(bridgeProducerConsumer.getProducer().getJob()); // 等待 producer 成功发送 100 条消息 ClientUtils.waitForClientSuccess(namespace, producerName, messageCount); // 部署原生 Kafka consumer Job KafkaProducerConsumer producerConsumer kafkaProducerConsumerBuilder .withConsumerName(testStorage.getConsumerName()) .withTopicName(testStorage.getTopicName()) .withConsumerGroup(ClientUtils.generateRandomConsumerGroup()) .build(); KubeResourceManager.get().createResourceWithWait(producerConsumer.getConsumer().getJob()); // 等待 consumer 成功消费 100 条消息 ClientUtils.waitForClientSuccess(namespace, consumerName, messageCount);其中NetworkPolicyUtils.allowNetworkPolicyForBridgeClient在命名空间存在 NetworkPolicy 管控时为 HTTP producer 的 Pod 放行到 Bridge 的网络访问保证 HTTPS 请求可达见 NetworkPolicyUtils.java。ClientUtils.waitForClientSuccess通过轮询客户端 Job 的完成状态与消息计数来判定成功见 ClientUtils.java其内部同时校验「Job 成功完成」与「消息数量达到预期」两个条件防止出现Job 跑完但消息数不足的假阳性。测试用例二testReceiveSimpleMessageTls——Kafka 生产HTTPS 消费验证描述验证在并行环境下可以使用 TLS 接收简单消息。该用例的业务链路与用例一相反Kafka Producer → Kafka Topic → Kafka Bridge →HTTPS 8443→ HTTP Consumer验证消息能从 Kafka 经 Bridge 通过 HTTPS 被 HTTP 客户端正确拉取。文档定义的逐步流程如下| 步骤 | 动作 | 结果 | | - | - | - | | 1 | 初始化 TestStorage 与 BridgeClients | TestStorage 与 BridgeClients 初始化完成 | | 2 | 按提供配置创建 Kafka Topic | Kafka Topic 资源创建完成并可用 | | 3 | 创建带 TLS 配置的 Kafka Bridge Client Job 用于消费消息 | 带 TLS 配置的 Kafka Bridge Client 创建完成并开始消费 | | 4 | 创建 Kafka 客户端用于生产消息 | Kafka 客户端配置并初始化完成 | | 5 | 验证 producer 成功发送消息 | Kafka producer 成功启动并开始发送消息 | | 6 | 验证消息消费 | Kafka Bridge consumer 成功消费消息 |源码实现要点// 为 HTTP consumer 放行访问 Bridge 的 NetworkPolicy NetworkPolicyUtils.allowNetworkPolicyForBridgeClient( testStorage.getNamespaceName(), suiteTestStorage.getClusterName(), testStorage.getConsumerName()); HttpProducerConsumer bridgeProducerConsumer httpProducerConsumerBuilder .withTopicName(testStorage.getTopicName()) .withConsumerName(testStorage.getConsumerName()) .withConsumerGroup(ClientUtils.generateRandomConsumerGroup()) .build(); // 创建 Topic KubeResourceManager.get().createResourceWithWait( KafkaTopicTemplates.topic(namespace, topicName, clusterName).build()); // 先启动 HTTP consumer Job通过 HTTPS 订阅并消费 KubeResourceManager.get().createResourceWithWait(bridgeProducerConsumer.getConsumer().getJob()); // 再启动 Kafka producer Job 向 Topic 生产消息 KafkaProducerConsumer producerConsumer kafkaProducerConsumerBuilder .withProducerName(testStorage.getProducerName()) .withTopicName(testStorage.getTopicName()) .build(); KubeResourceManager.get().createResourceWithWait(producerConsumer.getProducer().getJob()); // 同时等待 producer 发送成功与 consumer 消费成功 ClientUtils.waitForClientsSuccess(namespace, consumerName, producerName, messageCount);这里有一个值得注意的时序设计HTTP consumer 先于 Kafka producer 启动。配合setUp()中配置的auto.offset.resetearliest即使消息在 consumer 订阅之后才生产consumer 也能从最早的 offset 开始完整消费从而保证 100 条消息全部被验证见 ClientUtils.java 的waitForClientsSuccess双端等待。两个用例均以ParallelTest注解标记见 HttpBridgeServerTlsST.java说明它们可与其他ParallelTest用例并行执行——这也是为什么用例内部都通过TestStorage生成彼此隔离的命名空间与资源名避免并行冲突。KafkaBridge HTTPS 配置模型的源码级解析以上测试所验证的正是 KafkaBridge 自定义资源的spec.http.tls配置段。在 API 模型层该配置由三个类构成理解它们有助于在生产环境中正确编写 Bridge TLS 配置。KafkaBridgeHttpConfigHTTP 服务配置入口KafkaBridgeHttpConfig.java 是spec.http的模型类字段顺序为{port, tls, cors}port服务器监听端口默认值 8080校验约束Minimum(1023)——即 HTTPS 端口必须大于 1023避免与特权端口冲突测试中使用的 8443 正符合该约束tls类型为KafkaBridgeHttpTls即「TLS 配置用于客户端连接到 HTTP Bridge」cors类型为KafkaBridgeHttpCors用于跨域配置本套件未涉及。KafkaBridgeHttpTls证书引用与附加配置KafkaBridgeHttpTls.java 是http.tls的模型类certificateAndKey必填字段JsonProperty(required true)引用存放证书与私钥对的 Secret类型为CertAndKeySecretSourceconfigHTTP 服务器 TLS 的附加配置项类型为MapString, Object。该字段有一个重要的前缀约束不允许设置以ssl.开头的属性唯一例外是ssl.enabled.cipher.suites与ssl.enabled.protocols两个白名单项。这一约束从模型层阻止了用户通过附加配置覆盖由certificateAndKey管理的核心 TLS 属性避免了配置冲突。CertAndKeySecretSource证书与密钥的来源CertAndKeySecretSource.java 是通用证书密钥引用模型字段顺序为{secretName, certificate, key}secretName包含证书的 Secret 名称certificateSecret 中证书文件的名称keySecret 中私钥文件的名称。该模型同样被 Kafka 客户端 TLS 认证等场景复用是整个 Strimzi 证书引用体系的基础组件。一份完整的 KafkaBridge HTTPS 配置示例仓库自带的官方示例 kafka-bridge-tls.yaml 展示了最简洁的 Bridge TLS 写法apiVersion: kafka.strimzi.io/v1 kind: KafkaBridge metadata: name: my-bridge spec: replicas: 1 bootstrapServers: my-cluster-kafka-bootstrap:9092 http: port: 8443 tls: certificateAndKey: secretName: my-bridge-cert-secret certificate: cert.crt key: key.key将其与测试套件中的写法对照可以看出测试套件省略了secretName之外的显式文件名是因为 KafkaUser 凭据 Secret 的标准条目就是user.crt/user.key。在你的生产环境中若使用 cert-manager 或自签证书只要把certificate/key指向 Secret 中实际的文件名即可。底层逻辑从 CR 到 HTTPS 监听从代码结构看Strimzi Cluster Operator 在部署 Bridge 时读取上述spec.http.tls配置将certificateAndKey引用的 Secret 内容挂载到 Bridge Pod并据此生成 HTTPS 监听器配置config字段中白名单外的ssl.前缀属性被模型层直接拒绝从而保证服务端 TLS 行为可预期。测试用例通过HttpProducerConsumerBuilder.withSslTruststoreCertificate(...)建立的 Truststore 正是该 HTTPS 服务端的信任锚二者共同完成了服务端证书链的闭环验证。如何运行与扩展验证运行测试套件该套件是 Strimzi 系统测试systemtest的一部分需要已就绪的 Kubernetes/OpenShift 集群与可用的镜像仓库。运行方式与仓库其他系统测试一致例如通过 Maven 按标签或类名过滤执行# 在 systemtest 模块下运行本套件示例具体参数以仓库 Makefile / 测试文档为准 mvn verify -pl systemtest -DgroupsBRIDGE -Dit.testHttpBridgeServerTlsST其中-DgroupsBRIDGE对应测试类上的Tag(BRIDGE)标签也可使用REGRESSION或ACCEPTANCE标签过滤。完整的测试执行入口、镜像准备与参数说明可参考 TESTING.md 与 run_tests.sh。测试期间如何观察验证结果运行过程中可通过以下方式核对测试断言查看 Kafka Bridge 日志确认 HTTPS 监听器在 8443 端口启动、TLS 握手正常查看 HTTP producer/consumer 客户端 JobClientUtils.waitForClientSuccess会在消息数未达预期默认 100时持续轮询直至超时失败确认 KafkaUser Secretkubectl get secret bridge-service-name -o yaml中应包含user.crt/user.key条目且证书 CN 为 Bridge Service 名。扩展方向如果你希望基于本套件扩展验证场景仓库中还提供了相邻的 TLS 相关测试可供参考HttpBridgeTlsST验证 Kafka 客户端对 Bridge 的 TLS 客户端认证双向 TLS 方向HttpBridgeScramShaST验证 SCRAM-SHA 认证下的 Bridge 消息收发HttpBridgeCorsST验证http.cors跨域配置。结合HttpBridgeServerTlsST、HttpBridgeST与上述套件即可覆盖 Bridge「明文、服务端 TLS、客户端认证 TLS、SCRAM-SHA、CORS」等全部 HTTP 传输与安全维度这也正对应 bridge 标签对 Kafka Bridge 组件「各种配置、安全协议与网络场景」的全面验证目标。小结HttpBridgeServerTlsST是一个典型的端到端 TLS 验证套件其价值体现在两个层面测试设计层面巧妙地利用 KafkaUser 证书签发机制为 Bridge 服务端生成证书CN 与 Bridge Service 名一致并以「HTTP Producer 生产 Kafka Consumer 验证」「Kafka Producer 生产 HTTP Consumer 验证」两个反向链路完整覆盖 HTTPS 双向数据路径ParallelTest与按用例隔离的TestStorage设计保证了并行安全。配置实践层面它演示了 KafkaBridge CR 中spec.http.port、spec.http.tls.certificateAndKey的标准用法配合 API 模型层KafkaBridgeHttpTls的必填校验与ssl.前缀白名单约束为在生产环境为 Kafka Bridge 启用 HTTPS 提供了可直接复用的参考模板与验证依据。【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 9:55:11 · 阅读 1.2k Strimzi Kafka Bridge 服务端 TLS 支持验证：HttpBridgeServerTlsST 系统测试套件深度解析
Strimzi Kafka Bridge 服务端 TLS 支持验证HttpBridgeServerTlsST 系统测试套件深度解析【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator导读本文聚焦 Strimzi Kafka Operator 仓库中用于验证 Kafka Bridge HTTP 服务端 TLS 能力的系统测试套件HttpBridgeServerTlsST完整梳理其前置部署流程、两个核心测试用例的逐步执行逻辑并结合仓库源码剖析 KafkaBridge 资源中http.tls配置模型的底层实现与字段约束。读完本文你将掌握 Strimzi 如何通过 KafkaUser 生成 Bridge 服务端证书、如何在 KafkaBridge CR 中启用 HTTPS、以及系统测试如何端到端验证「HTTP over TLS 生产/消费」全链路。测试套件定位验证 Kafka Bridge 服务端 TLS在 Strimzi 生态中Kafka Bridge 承担着 HTTP 客户端与 Kafka 集群之间的协议转换角色将 REST API 与 Kafka 消息系统集成起来。当 HTTP 客户端与 Bridge 之间需要加密传输时就必须为 Bridge 的 HTTP 服务端启用 TLS。HttpBridgeServerTlsST正是负责验证这一能力的系统测试套件。该套件定义于源码文件 HttpBridgeServerTlsST.java其官方描述为Test suite for verifying TLS support for HTTP Bridge server.验证 HTTP Bridge 服务器 TLS 支持的测试套件套件级注解SuiteDoc中给出的完整语义如下描述验证 HTTP Bridge 服务器的 TLS 支持。标签Labelsbridge归属于 bridge 测试标签体系同时测试类上还标有Tag(REGRESSION)、Tag(BRIDGE)、Tag(ACCEPTANCE)三个 JUnit 标签分别对应回归、Bridge 组件、验收三类测试分组。与仅验证明文 HTTP 的HttpBridgeST、验证客户端认证的HttpBridgeTlsSTTLS 客户端认证以及 SCRAM-SHA 认证的HttpBridgeScramShaST不同本套件的核心关注点在于Bridge 服务端自己提供 TLS 证书、以 HTTPS 协议对外提供服务测试中的 HTTP 客户端通过信任该服务端证书来建立加密连接。套件级前置步骤四步准备 TLS 运行环境根据套件文档在执行任何测试用例之前必须先完成以下四个前置步骤| 步骤 | 动作 | 预期结果 | | - | - | - | | 1 | 初始化测试存储与上下文 | 测试存储与上下文初始化成功 | | 2 | 创建 KafkaUser 以生成 HTTP Bridge 服务器证书与密钥 | 用于生成 HTTP Bridge 服务器证书与密钥的 KafkaUser 已创建 | | 3 | 部署配置了 HTTP Bridge 服务器证书与密钥的 Kafka 与 KafkaBridge | Kafka 与 KafkaBridge 已部署并正常运行 | | 4 | 创建 BridgeClients 实例 | BridgeClients 实例已创建 |上述步骤在源码中由BeforeAll修饰的setUp()方法实现其执行流程与文档一一对应并蕴含了 Strimzi 的一个关键设计利用 User Operator 为 TLS 用户签发证书的机制来为 Bridge 服务端生成证书。步骤 1初始化测试存储suiteTestStorage new TestStorage(KubeResourceManager.get().getTestContext());TestStorage是系统测试中统一管理命名空间、集群名、Topic 名、用户名、消息数量等测试数据的存储类见 TestStorage.java。其中消息数量默认值为MESSAGE_COUNT 100见 TestConstants.java意味着每个用例默认验证 100 条消息的端到端传输。随后通过SetupClusterOperator.getInstance().withDefaultConfiguration().install()安装 Cluster Operator含 CRD、ServiceAccount、RBAC 与 Deployment这是所有系统测试的运行前提。步骤 2创建 KafkaUser 生成服务端证书与密钥这是本套件最值得注意的设计点。Strimzi 中 KafkaUser 资源在启用 TLS 客户端认证后User Operator 会为其生成证书与私钥。本套件巧妙地复用了这一能力——让 KafkaUser 的名称与 KafkaBridge 的 Service 名称一致从而让生成的证书以 Bridge Service 名为 CN直接充当 Bridge 的 HTTPS 服务端证书// Create KafkaUser to generate the HTTP Bridge server certificate and key // The KafkaBridge serviceName will be used as the CN for the HTTP Bridge server certificate KafkaUser tlsUser KafkaUserTemplates.tlsUser( Environment.TEST_SUITE_NAMESPACE, KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName()), suiteTestStorage.getClusterName()).build(); KubeResourceManager.get().createResourceWithWait(tlsUser);从模板实现看tlsUser() 构建的 KafkaUser 规格为spec: authentication: type: tls即KafkaUserTlsClientAuthentication类型。该用户创建成功后其凭据 Secret名称与用户名一致即 Bridge Service 名中包含ca.crt、user.crt、user.key等条目其中user.crt/user.key即后续 Bridge HTTPS 使用的服务端证书与密钥。步骤 3部署 Kafka 与启用 TLS 的 KafkaBridge首先部署 Kafka 集群。源码使用 KRaft 模式下的 NodePool 布局分别创建 Broker 与 Controller 两个持久化 NodePool再创建 Kafka 集群KubeResourceManager.get().createResourceWithWait( KafkaNodePoolTemplates.brokerPoolPersistentStorage(namespace, brokerPoolName, clusterName, 1).build(), KafkaNodePoolTemplates.controllerPoolPersistentStorage(namespace, controllerPoolName, clusterName, 1).build()); KubeResourceManager.get().createResourceWithWait(KafkaTemplates.kafka(namespace, clusterName, 1).build());随后部署 KafkaBridge。关键在.editSpec()中对http段的配置KubeResourceManager.get().createResourceWithWait(KafkaBridgeTemplates.kafkaBridge( namespace, clusterName, KafkaResources.plainBootstrapAddress(clusterName), 1) .editSpec() .withNewConsumer() .addToConfig(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, earliest) .endConsumer() .withNewHttp() .withPort(8443) .withNewTls() .withNewCertificateAndKey() .withSecretName(KafkaBridgeResources.serviceName(clusterName)) .withCertificate(user.crt) .withKey(user.key) .endCertificateAndKey() .endTls() .endHttp() .endSpec() .build());对照默认模板KafkaBridgeTemplates.java可以看出默认的kafkaBridge()仅配置bootstrapServers、replicas、DEBUG 级日志与port: 8080的明文 HTTP本用例在此基础上叠加了HTTPS 端口 8443 与服务端证书引用。这里形成的 TLS 配置语义为| 字段 | 取值 | 含义 | | - | - | - | |http.port|8443| HTTPS 监听端口需大于 1023 | |http.tls.certificateAndKey.secretName| Bridge 的 Service 名 | 存放证书与密钥的 Secret 名称即上一步 KafkaUser 的凭据 Secret | |http.tls.certificateAndKey.certificate|user.crt| Secret 中证书文件名 | |http.tls.certificateAndKey.key|user.key| Secret 中私钥文件名 |另外consumer段设置了auto.offset.resetearliest确保后续 HTTP 消费者从最早的 offset 开始消费从而可靠地收到测试消息。步骤 4创建 BridgeClients 实例前置最后一步构建两类客户端构建器供两个测试用例复用kafkaProducerConsumerBuilder new KafkaProducerConsumerBuilder() .withNamespaceName(suiteTestStorage.getNamespaceName()) .withMessageCount(suiteTestStorage.getMessageCount()) .withTopicName(suiteTestStorage.getTopicName()) .withBootstrapAddress(KafkaResources.plainBootstrapAddress(suiteTestStorage.getClusterName())); httpProducerConsumerBuilder new HttpProducerConsumerBuilder() .withHostname(KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName())) .withTopicName(suiteTestStorage.getTopicName()) .withMessageCount(suiteTestStorage.getMessageCount()) .withPort(8443) .withNamespaceName(Environment.TEST_SUITE_NAMESPACE) .withSslTruststoreCertificate(KafkaBridgeResources.serviceName(suiteTestStorage.getClusterName()));值得注意的是httpProducerConsumerBuilder的两个参数withPort(8443)HTTP 客户端必须访问 Bridge 的 HTTPS 端口withSslTruststoreCertificate(serviceName)客户端以 Bridge Service 名为信任源构建 Truststore即信任服务端证书这是 HTTPS 客户端侧建立信任链的关键。测试用例一testSendSimpleMessageTls——HTTPS 生产Kafka 消费验证描述验证使用 TLS 发送简单消息是否正确工作。该用例的业务链路为HTTP Producer →HTTPS 8443→ Kafka Bridge → Kafka Topic → Kafka Consumer即验证消息经 HTTPS 进入 Bridge 后能正确落入 Kafka。文档定义的逐步流程如下| 步骤 | 动作 | 结果 | | - | - | - | | 1 | 初始化 TestStorage 与 BridgeClients | TestStorage 与 BridgeClients 初始化完成 | | 2 | 使用资源管理器创建 Kafka Topic | Kafka Topic 创建成功 | | 3 | 创建带 TLS 配置的 Kafka Bridge Client Job 用于生产消息 | 带 TLS 配置的 Kafka Bridge Client Job 创建成功并生产消息 | | 4 | 验证 producer 成功发送消息 | Producer 成功发送预期数量的消息 | | 5 | 创建 Kafka 客户端用于消费 | Kafka 客户端 consumer 创建完成 | | 6 | 验证 consumer 成功接收消息 | Consumer 成功接收预期数量的消息 |源码实现要点// 为 HTTP producer 放行访问 Bridge 的 NetworkPolicy NetworkPolicyUtils.allowNetworkPolicyForBridgeClient( testStorage.getNamespaceName(), suiteTestStorage.getClusterName(), testStorage.getProducerName()); HttpProducerConsumer bridgeProducerConsumer httpProducerConsumerBuilder .withTopicName(testStorage.getTopicName()) .withProducerName(testStorage.getProducerName()) .build(); // 创建 Topic KubeResourceManager.get().createResourceWithWait( KafkaTopicTemplates.topic(namespace, topicName, clusterName).build()); // 部署 HTTP producer JobHTTPS 访问 Bridge 8443 KubeResourceManager.get().createResourceWithWait(bridgeProducerConsumer.getProducer().getJob()); // 等待 producer 成功发送 100 条消息 ClientUtils.waitForClientSuccess(namespace, producerName, messageCount); // 部署原生 Kafka consumer Job KafkaProducerConsumer producerConsumer kafkaProducerConsumerBuilder .withConsumerName(testStorage.getConsumerName()) .withTopicName(testStorage.getTopicName()) .withConsumerGroup(ClientUtils.generateRandomConsumerGroup()) .build(); KubeResourceManager.get().createResourceWithWait(producerConsumer.getConsumer().getJob()); // 等待 consumer 成功消费 100 条消息 ClientUtils.waitForClientSuccess(namespace, consumerName, messageCount);其中NetworkPolicyUtils.allowNetworkPolicyForBridgeClient在命名空间存在 NetworkPolicy 管控时为 HTTP producer 的 Pod 放行到 Bridge 的网络访问保证 HTTPS 请求可达见 NetworkPolicyUtils.java。ClientUtils.waitForClientSuccess通过轮询客户端 Job 的完成状态与消息计数来判定成功见 ClientUtils.java其内部同时校验「Job 成功完成」与「消息数量达到预期」两个条件防止出现Job 跑完但消息数不足的假阳性。测试用例二testReceiveSimpleMessageTls——Kafka 生产HTTPS 消费验证描述验证在并行环境下可以使用 TLS 接收简单消息。该用例的业务链路与用例一相反Kafka Producer → Kafka Topic → Kafka Bridge →HTTPS 8443→ HTTP Consumer验证消息能从 Kafka 经 Bridge 通过 HTTPS 被 HTTP 客户端正确拉取。文档定义的逐步流程如下| 步骤 | 动作 | 结果 | | - | - | - | | 1 | 初始化 TestStorage 与 BridgeClients | TestStorage 与 BridgeClients 初始化完成 | | 2 | 按提供配置创建 Kafka Topic | Kafka Topic 资源创建完成并可用 | | 3 | 创建带 TLS 配置的 Kafka Bridge Client Job 用于消费消息 | 带 TLS 配置的 Kafka Bridge Client 创建完成并开始消费 | | 4 | 创建 Kafka 客户端用于生产消息 | Kafka 客户端配置并初始化完成 | | 5 | 验证 producer 成功发送消息 | Kafka producer 成功启动并开始发送消息 | | 6 | 验证消息消费 | Kafka Bridge consumer 成功消费消息 |源码实现要点// 为 HTTP consumer 放行访问 Bridge 的 NetworkPolicy NetworkPolicyUtils.allowNetworkPolicyForBridgeClient( testStorage.getNamespaceName(), suiteTestStorage.getClusterName(), testStorage.getConsumerName()); HttpProducerConsumer bridgeProducerConsumer httpProducerConsumerBuilder .withTopicName(testStorage.getTopicName()) .withConsumerName(testStorage.getConsumerName()) .withConsumerGroup(ClientUtils.generateRandomConsumerGroup()) .build(); // 创建 Topic KubeResourceManager.get().createResourceWithWait( KafkaTopicTemplates.topic(namespace, topicName, clusterName).build()); // 先启动 HTTP consumer Job通过 HTTPS 订阅并消费 KubeResourceManager.get().createResourceWithWait(bridgeProducerConsumer.getConsumer().getJob()); // 再启动 Kafka producer Job 向 Topic 生产消息 KafkaProducerConsumer producerConsumer kafkaProducerConsumerBuilder .withProducerName(testStorage.getProducerName()) .withTopicName(testStorage.getTopicName()) .build(); KubeResourceManager.get().createResourceWithWait(producerConsumer.getProducer().getJob()); // 同时等待 producer 发送成功与 consumer 消费成功 ClientUtils.waitForClientsSuccess(namespace, consumerName, producerName, messageCount);这里有一个值得注意的时序设计HTTP consumer 先于 Kafka producer 启动。配合setUp()中配置的auto.offset.resetearliest即使消息在 consumer 订阅之后才生产consumer 也能从最早的 offset 开始完整消费从而保证 100 条消息全部被验证见 ClientUtils.java 的waitForClientsSuccess双端等待。两个用例均以ParallelTest注解标记见 HttpBridgeServerTlsST.java说明它们可与其他ParallelTest用例并行执行——这也是为什么用例内部都通过TestStorage生成彼此隔离的命名空间与资源名避免并行冲突。KafkaBridge HTTPS 配置模型的源码级解析以上测试所验证的正是 KafkaBridge 自定义资源的spec.http.tls配置段。在 API 模型层该配置由三个类构成理解它们有助于在生产环境中正确编写 Bridge TLS 配置。KafkaBridgeHttpConfigHTTP 服务配置入口KafkaBridgeHttpConfig.java 是spec.http的模型类字段顺序为{port, tls, cors}port服务器监听端口默认值 8080校验约束Minimum(1023)——即 HTTPS 端口必须大于 1023避免与特权端口冲突测试中使用的 8443 正符合该约束tls类型为KafkaBridgeHttpTls即「TLS 配置用于客户端连接到 HTTP Bridge」cors类型为KafkaBridgeHttpCors用于跨域配置本套件未涉及。KafkaBridgeHttpTls证书引用与附加配置KafkaBridgeHttpTls.java 是http.tls的模型类certificateAndKey必填字段JsonProperty(required true)引用存放证书与私钥对的 Secret类型为CertAndKeySecretSourceconfigHTTP 服务器 TLS 的附加配置项类型为MapString, Object。该字段有一个重要的前缀约束不允许设置以ssl.开头的属性唯一例外是ssl.enabled.cipher.suites与ssl.enabled.protocols两个白名单项。这一约束从模型层阻止了用户通过附加配置覆盖由certificateAndKey管理的核心 TLS 属性避免了配置冲突。CertAndKeySecretSource证书与密钥的来源CertAndKeySecretSource.java 是通用证书密钥引用模型字段顺序为{secretName, certificate, key}secretName包含证书的 Secret 名称certificateSecret 中证书文件的名称keySecret 中私钥文件的名称。该模型同样被 Kafka 客户端 TLS 认证等场景复用是整个 Strimzi 证书引用体系的基础组件。一份完整的 KafkaBridge HTTPS 配置示例仓库自带的官方示例 kafka-bridge-tls.yaml 展示了最简洁的 Bridge TLS 写法apiVersion: kafka.strimzi.io/v1 kind: KafkaBridge metadata: name: my-bridge spec: replicas: 1 bootstrapServers: my-cluster-kafka-bootstrap:9092 http: port: 8443 tls: certificateAndKey: secretName: my-bridge-cert-secret certificate: cert.crt key: key.key将其与测试套件中的写法对照可以看出测试套件省略了secretName之外的显式文件名是因为 KafkaUser 凭据 Secret 的标准条目就是user.crt/user.key。在你的生产环境中若使用 cert-manager 或自签证书只要把certificate/key指向 Secret 中实际的文件名即可。底层逻辑从 CR 到 HTTPS 监听从代码结构看Strimzi Cluster Operator 在部署 Bridge 时读取上述spec.http.tls配置将certificateAndKey引用的 Secret 内容挂载到 Bridge Pod并据此生成 HTTPS 监听器配置config字段中白名单外的ssl.前缀属性被模型层直接拒绝从而保证服务端 TLS 行为可预期。测试用例通过HttpProducerConsumerBuilder.withSslTruststoreCertificate(...)建立的 Truststore 正是该 HTTPS 服务端的信任锚二者共同完成了服务端证书链的闭环验证。如何运行与扩展验证运行测试套件该套件是 Strimzi 系统测试systemtest的一部分需要已就绪的 Kubernetes/OpenShift 集群与可用的镜像仓库。运行方式与仓库其他系统测试一致例如通过 Maven 按标签或类名过滤执行# 在 systemtest 模块下运行本套件示例具体参数以仓库 Makefile / 测试文档为准 mvn verify -pl systemtest -DgroupsBRIDGE -Dit.testHttpBridgeServerTlsST其中-DgroupsBRIDGE对应测试类上的Tag(BRIDGE)标签也可使用REGRESSION或ACCEPTANCE标签过滤。完整的测试执行入口、镜像准备与参数说明可参考 TESTING.md 与 run_tests.sh。测试期间如何观察验证结果运行过程中可通过以下方式核对测试断言查看 Kafka Bridge 日志确认 HTTPS 监听器在 8443 端口启动、TLS 握手正常查看 HTTP producer/consumer 客户端 JobClientUtils.waitForClientSuccess会在消息数未达预期默认 100时持续轮询直至超时失败确认 KafkaUser Secretkubectl get secret bridge-service-name -o yaml中应包含user.crt/user.key条目且证书 CN 为 Bridge Service 名。扩展方向如果你希望基于本套件扩展验证场景仓库中还提供了相邻的 TLS 相关测试可供参考HttpBridgeTlsST验证 Kafka 客户端对 Bridge 的 TLS 客户端认证双向 TLS 方向HttpBridgeScramShaST验证 SCRAM-SHA 认证下的 Bridge 消息收发HttpBridgeCorsST验证http.cors跨域配置。结合HttpBridgeServerTlsST、HttpBridgeST与上述套件即可覆盖 Bridge「明文、服务端 TLS、客户端认证 TLS、SCRAM-SHA、CORS」等全部 HTTP 传输与安全维度这也正对应 bridge 标签对 Kafka Bridge 组件「各种配置、安全协议与网络场景」的全面验证目标。小结HttpBridgeServerTlsST是一个典型的端到端 TLS 验证套件其价值体现在两个层面测试设计层面巧妙地利用 KafkaUser 证书签发机制为 Bridge 服务端生成证书CN 与 Bridge Service 名一致并以「HTTP Producer 生产 Kafka Consumer 验证」「Kafka Producer 生产 HTTP Consumer 验证」两个反向链路完整覆盖 HTTPS 双向数据路径ParallelTest与按用例隔离的TestStorage设计保证了并行安全。配置实践层面它演示了 KafkaBridge CR 中spec.http.port、spec.http.tls.certificateAndKey的标准用法配合 API 模型层KafkaBridgeHttpTls的必填校验与ssl.前缀白名单约束为在生产环境为 Kafka Bridge 启用 HTTPS 提供了可直接复用的参考模板与验证依据。【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考