第 15 章 保护对 Kafka 集群的访问


通过配置 Kafka 和 Kafka 用户进行安全连接。通过配置,您可以实施加密、身份验证和授权机制。

Kafka 配置

要建立对 Kafka 的安全访问,请将 Kafka 资源配置为根据您的特定要求设置以下配置:

  • 带有指定身份验证类型的监听程序来定义客户端如何进行身份验证

    • TLS 加密,用于 Kafka 和客户端之间的通信
    • 支持 TLS 版本和密码套件以提高安全性
  • 整个 Kafka 集群的授权
  • 用于限制访问的网络策略
  • 超级用户对代理的访问没有限制

身份验证是为每个监听程序独立配置的,而为整个 Kafka 集群设置授权。

有关 Kafka 访问配置的更多信息,请参阅 Kafka 模式参考GenericKafkaListener 模式参考

用户(客户端)配置

要启用对 Kafka 的安全客户端访问,请配置 KafkaUser 资源。这些资源代表客户端,并确定它们如何与 Kafka 集群验证和授权。

KafkaUser 资源配置为根据您的特定要求设置以下配置:

  • 必须与启用的监听程序身份验证匹配的身份验证

    • 支持的 TLS 版本和密码套件必须与 Kafka 配置匹配
  • 应用访问控制列表(ACL)规则的简单授权

    • ACL 用于精细控制用户对主题和操作的访问
  • 根据字节率或 CPU 使用率限制客户端访问的配额

User Operator 根据所选的验证类型,创建代表客户端的用户以及用于客户端身份验证的安全凭证。

有关用户访问配置的更多信息,请参阅 KafkaUser 模式参考

15.1. 在监听器中配置客户端身份验证

在创建监听程序时为 Kafka 代理配置客户端身份验证。使用 Kafka 资源中的 Kafka.spec.kafka.listeners.authentication 属性指定监听程序验证类型。

对于 OpenShift 集群中的客户端,您可以创建 plain (没有加密)或 tls 内部监听程序内部监听程序 类型使用无头服务,以及提供给代理 pod 的 DNS 名称。作为无头服务的替代选择,您还可以创建内部监听程序的 cluster-ip 类型,以使用每个代理的 ClusterIP 服务公开 Kafka。对于 OpenShift 集群外的客户端,您可以创建 外部监听程序 并指定连接机制,可以是 nodeportloadbalanceringress (仅限 Kubernetes) 或路由 (仅限 OpenShift)。

有关连接外部客户端的配置选项的详情请参考 第 14 章 设置 Kafka 集群的客户端访问权限

支持的身份验证选项:

  1. mTLS 身份验证(只在启用了 TLS 的监听程序中)
  2. SCRAM-SHA-512 身份验证
  3. 基于 OAuth 2.0 令牌的身份验证
  4. 自定义身份验证
  5. TLS 版本和密码套件

如果您使用 OAuth 2.0 进行客户端访问管理,则用户身份验证和授权凭证将通过授权服务器处理。

您选择的身份验证选项取决于您如何验证客户端对 Kafka 代理的访问。

注意

在使用自定义身份验证前,尝试了解标准身份验证选项。自定义身份验证允许任何类型的 Kafka 支持的身份验证。它可以提供更大的灵活性,但也增加了复杂性。

图 15.1. Kafka 侦听器身份验证选项

listener authentication 属性用于指定特定于该侦听器的身份验证机制。

如果没有指定 身份验证 属性,则监听器不会验证通过该监听程序连接的客户端。侦听器将在没有身份验证的情况下接受所有连接。

在使用 User Operator 管理 KafkaUsers 时,必须配置身份验证。

以下示例显示了:

  • 为 SCRAM-SHA-512 身份验证配置 纯文本
  • 带有 mTLS 验证的 tls 侦听器
  • 带有 mTLS 验证的 外部监听程序

每个监听程序都配置在 Kafka 集群中具有唯一的名称和端口。

重要

当为客户端配置监听程序对代理的访问时,您可以使用端口 9092 或更高版本(9093、9094 等),但有一些例外。侦听程序无法配置为使用为 interbroker 通信(9090 和 9091)、Prometheus 指标(9404)和 JMX (Java 管理扩展)监控(9999)保留的端口。

侦听器身份验证配置示例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: true
        authentication:
          type: scram-sha-512
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: tls
# ...
Copy to Clipboard Toggle word wrap

15.1.1. mTLS 身份验证

mTLS 身份验证总是用于 Kafka 代理和 ZooKeeper pod 之间的通信。

Apache Kafka 的流可将 Kafka 配置为使用 TLS (传输层安全)来提供 Kafka 代理和客户端之间的加密通信,而无需 mutual 身份验证。对于 mutual,或双向验证,服务器和客户端都存在证书。当您配置 mTLS 身份验证时,代理会验证客户端(客户端身份验证),客户端会验证代理(服务器身份验证)。

Kafka 资源中的 mTLS 侦听器配置需要以下内容:

  • tls: true 指定 TLS 加密和服务器身份验证
  • authentication.type: tls 来指定客户端身份验证

当 Cluster Operator 创建 Kafka 集群时,它会创建一个名为 < cluster_name>-cluster-ca-cert 的新 secret。secret 包含 CA 证书。CA 证书采用 PEM 和 PKCS #12 格式。要验证 Kafka 集群,请将 CA 证书添加到客户端配置中的信任存储中。若要验证客户端,请在客户端配置中添加用户证书和密钥到密钥存储。有关为 mTLS 配置客户端的详情请参考 第 15.3.2 节 “配置用户身份验证”

注意

TLS 身份验证更为常见的单向,另一方验证另一方的身份。例如,当在 Web 浏览器和 Web 服务器之间使用 HTTPS 时,浏览器获取 Web 服务器身份的证明。

15.1.2. SCRAM-SHA-512 身份验证

SCRAM (Salted Challenge Response Authentication Mechanism)是一个身份验证协议,可以使用密码建立 mutual 身份验证。Apache Kafka 的流可将 Kafka 配置为使用 SASL (Simple Authentication and Security Layer) SCRAM-SHA-512,以便在未加密的和加密的客户端连接上提供身份验证。

当 SCRAM-SHA-512 身份验证与 TLS 连接一起使用时,TLS 协议会提供加密,但不用于身份验证。

以下 SCRAM 属性使得在未加密的连接中也安全地使用 SCRAM-SHA-512 :

  • 密码不会通过通信通道以明文形式发送。取而代之,客户端和服务器都是由另一个挑战的挑战,以提供对其了解验证用户的密码的证明。
  • 服务器和客户端各自为每个身份验证交换生成一个新的挑战。这意味着,交换具有弹性地应对重播攻击。

当使用 scram-sha-512 配置 KafkaUser.spec.authentication.type 时,User Operator 将生成一个由大写和小写 ASCII 字母和数字组成的随机 32 个字符密码。

15.1.3. 使用网络策略限制对监听程序的访问

通过在 Kafka 资源中配置 networkPolicyPeers 属性来控制监听程序访问。

默认情况下,Apache Kafka 的 Streams 会自动为每个启用的 Kafka 侦听器创建一个 NetworkPolicy 资源,允许从所有命名空间的连接。

要限制对网络级别的特定应用程序或命名空间的监听程序访问,请配置 networkPolicyPeers 属性。每个监听程序都可以有自己的 networkPolicyPeers 配置。有关网络策略对等点的更多信息,请参阅 NetworkPolicyPeer API 参考

如果要使用自定义网络策略,您可以在 Cluster Operator 配置中将 STRIMZI_NETWORK_POLICY_GENERATION 环境变量设置为 false。如需更多信息,请参阅 第 9.6 节 “配置 Cluster Operator”

注意

您的 OpenShift 配置必须支持 ingress NetworkPolicies 才能使用网络策略。

先决条件

  • 支持 Ingress NetworkPolicies 的 OpenShift 集群。
  • Cluster Operator 正在运行。

流程

  1. 配置 networkPolicyPeers 属性,以定义允许访问 Kafka 集群的应用程序 pod 或命名空间。

    本例演示了 tls 侦听器的配置,仅允许来自应用程序 pod 的连接,标签 app 设置为 kafka-client

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
            networkPolicyPeers:
              - podSelector:
                  matchLabels:
                    app: kafka-client
        # ...
      zookeeper:
        # ...
    Copy to Clipboard Toggle word wrap
  2. Kafka 资源配置应用更改。

15.1.4. 使用自定义监听程序证书进行 TLS 加密

此流程演示了如何为 TLS 侦听程序或启用了 TLS 加密的外部监听程序配置自定义服务器证书。

默认情况下,Kafka 侦听程序使用由 Streams 为 Apache Kafka 的内部 CA (证书颁发机构)签名的证书。Cluster Operator 在创建 Kafka 集群时自动生成 CA 证书。要为 TLS 配置客户端,CA 证书包含在其信任存储配置中以验证 Kafka 集群。或者,您可以选择 安装和使用自己的 CA 证书

但是,如果您想通过在监听器级别使用自己的自定义证书,您可以使用 brokerCertChainAndKey 属性配置监听程序。您可以使用自己的私钥和服务器证书创建一个 secret,然后在 brokerCertChainAndKey 配置中指定它们。

用户提供的证书允许您利用现有的安全基础架构。您可以使用由公共(外部)CA 或私有 CA 签名的证书。Kafka 客户端需要信任用于为监听器证书签名的 CA。如果由公共 CA 签名,通常不需要将其添加到客户端的信任存储配置中。

自定义证书不由 Apache Kafka 的 Streams 管理,因此您需要手动更新它们。

注意

侦听器证书仅用于 TLS 加密和服务器身份验证。它们不用于 TLS 客户端身份验证。如果还想将自己的证书用于 TLS 客户端身份验证,您必须安装和使用自己的客户端 CA

先决条件

  • Cluster Operator 正在运行。
  • 每个监听程序都需要以下内容:

如果您不使用自签名证书,您可以提供一个证书中包含整个 CA 链的证书。

如果为监听程序配置了 TLS 加密(tls: true),则只能使用 brokerCertChainAndKey 属性。

注意

Apache Kafka 的流不支持将加密私钥用于 TLS。存储在 secret 中的私钥必须未加密的才能正常工作。

流程

  1. 创建包含私钥和服务器证书的 Secret

    oc create secret generic <my_secret> --from-file=<my_listener_key.key> --from-file=<my_listener_certificate.crt>
    Copy to Clipboard Toggle word wrap
  2. 编辑集群的 Kafka 资源。

    将监听程序配置为在 configuration.brokerCertChainAndKey 属性中使用您的 Secret、证书文件和私钥文件。

    启用 TLS 加密的 loadbalancer 外部监听程序配置示例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...
    Copy to Clipboard Toggle word wrap

    TLS 侦听器配置示例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...
    Copy to Clipboard Toggle word wrap

  3. Kafka 资源配置应用更改。

    Cluster Operator 启动 Kafka 集群的滚动更新,该集群更新监听程序的配置。

    注意

    如果您在被监听程序使用的 Secret 中更新 Kafka 侦听器证书,也会启动滚动更新。

15.1.5. 为自定义监听程序证书指定 SAN

要将 TLS 主机名验证用于自定义 Kafka 侦听器证书,您必须为每个监听程序指定正确的主题备用名称(SAN)。

证书 SAN 必须为以下内容指定主机名:

  • 集群中的所有 Kafka 代理
  • Kafka 集群 bootstrap 服务

如果您的 CA 支持,您可以使用通配符证书。

15.1.5.1. 内部监听程序的 SAN 示例

使用以下示例帮助您为内部监听程序在证书中指定 SAN 的主机名。

<cluster-name > 替换为 Kafka 集群的名称,将 <namespace > 替换为运行集群的 OpenShift 命名空间。

类型的通配符示例:内部监听程序

//Kafka brokers
*.<cluster_name>-kafka-brokers
*.<cluster_name>-kafka-brokers.<namespace>.svc

// Bootstrap service
<cluster_name>-kafka-bootstrap
<cluster_name>-kafka-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

类型:内部监听程序 的非通配符示例

// Kafka brokers
<cluster_name>-kafka-0.<cluster_name>-kafka-brokers
<cluster_name>-kafka-0.<cluster_name>-kafka-brokers.<namespace>.svc
<cluster_name>-kafka-1.<cluster_name>-kafka-brokers
<cluster_name>-kafka-1.<cluster_name>-kafka-brokers.<namespace>.svc
# ...

// Bootstrap service
<cluster_name>-kafka-bootstrap
<cluster_name>-kafka-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

类型的非通配符示例:cluster-ip listener

// Kafka brokers
<cluster_name>-kafka-<listener-name>-0
<cluster_name>-kafka-<listener-name>-0.<namespace>.svc
<cluster_name>-kafka-_listener-name>-1
<cluster_name>-kafka-<listener-name>-1.<namespace>.svc
# ...

// Bootstrap service
<cluster_name>-kafka-<listener-name>-bootstrap
<cluster_name>-kafka-<listener-name>-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

15.1.5.2. 外部监听程序的 SAN 示例

对于启用了 TLS 加密的外部监听程序,您需要在证书中指定的主机名取决于外部监听程序 类型

Expand
表 15.1. 每个类型的外部监听程序的 sans
外部监听程序类型在 SANs 中,指定…​

Ingress

所有 Kafka 代理 Ingress 资源的地址以及 bootstrap Ingress 的地址。

您可以使用匹配的通配符名称。

route

所有 Kafka 代理 路由和 bootstrap 路由地址 的地址

您可以使用匹配的通配符名称。

loadbalancer

所有 Kafka 代理 负载均衡器 和 bootstrap 负载均衡器 地址

您可以使用匹配的通配符名称。

nodeport

Kafka 代理 pod 可能调度到的所有 OpenShift worker 节点的地址。

您可以使用匹配的通配符名称。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat