Kafka 安全之概览和监听器配置

2024-06-15 12:28

本文主要是介绍Kafka 安全之概览和监听器配置,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

一. 前言

二. Kafka 安全概览

三. 监听器配置(Listener Configuration)


一. 前言

    在配置 Kafka 监听器时,需要注意配置的一致性和正确性。确保 Kafka 集群和消费者端的监听器配置相匹配,避免因配置错误导致的连接问题和数据传输故障。通过正确配置 Kafka 的监听器类型、协议选择和安全性配置,可以实现消息传输和消费端访问的灵活和安全。根据应用需求和安全要求,选择合适的监听器配置,确保 Kafka 集群的可靠性和数据的安全性传输。

二. Kafka 安全概览

原文引用:In release 0.9.0.0, the Kafka community added a number of features that, used either separately or together, increases security in a Kafka cluster. The following security measures are currently supported:

  1. Authentication of connections to brokers from clients (producers and consumers), other brokers and tools, using either SSL or SASL. Kafka supports the following SASL mechanisms:
    1. SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0
    2. SASL/PLAIN - starting at version 0.10.0.0
    3. SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0
    4. SASL/OAUTHBEARER - starting at version 2.0
  2. Authentication of connections from brokers to ZooKeeper
  3. Encryption of data transferred between brokers and clients, between brokers, or between brokers and tools using SSL (Note that there is a performance degradation when SSL is enabled, the magnitude of which depends on the CPU type and the JVM implementation.)
  4. Authorization of read / write operations by clients
  5. Authorization is pluggable and integration with external authorization services is supported

    在 0.9.0.0 版本中,Kafka 社区添加了许多功能,这些功能可以单独使用,也可以一起使用,以提高 Kafka 集群的安全性。当前支持以下安全措施:

  1. 使用SSL或SASL验证客户端(生产者和消费者)、其他代理和工具与代理的连接。Kafka支持以下SASL机制:
    1. SASL/GSSAPI(Kerberos)- 从0.9.0.0版本开始
    2. SASL/PLAIN - 从版本0.10.0.0开始
    3. SASL/SCRAM-SHA-256 和 SASL/SCRAM-SHA-512 - 从版本0.10.2.0开始
    4. SASL/OAUTHBEARER - 从2.0版开始
  2. 从 Broker 到 ZooKeeper 的连接验证。
  3. 使用 SSL 对 Broker 和客户端之间、Broker 之间或 Broker 和工具之间传输的数据进行加密(请注意,启用 SSL 时会出现性能下降,其大小取决于 CPU 类型和 JVM 实现)。
  4. 客户端对读/写操作的授权。
  5. 授权是可插拔的,并且支持与外部授权服务集成。

原文引用:It's worth noting that security is optional - non-secured clusters are supported, as well as a mix of authenticated, unauthenticated, encrypted and non-encrypted clients. The guides below explain how to configure and use the security features in both clients and brokers.

    值得注意的是,安全性是可选的——支持非安全集群,以及已验证、未验证、加密和未加密客户端的混合。以下指南解释了如何在客户端和 Broker 中配置和使用安全功能。

三. 监听器配置(Listener Configuration)

原文引用:In order to secure a Kafka cluster, it is necessary to secure the channels that are used to communicate with the servers. Each server must define the set of listeners that are used to receive requests from clients as well as other servers. Each listener may be configured to authenticate clients using various mechanisms and to ensure traffic between the server and the client is encrypted. This section provides a primer for the configuration of listeners.

    为了保护 Kafka 集群的安全,有必要保护用于与服务器通信的通道。每个服务器都必须定义一组监听器,用于接收来自客户端和其他服务器的请求。每个监听器可以被配置为使用各种机制来认证客户端,并确保服务器和客户端之间的传输被加密。本节提供了监听器配置的入门知识。

原文引用:Kafka servers support listening for connections on multiple ports. This is configured through the listeners property in the server configuration, which accepts a comma-separated list of the listeners to enable. At least one listener must be defined on each server. The format of each listener defined in listeners is given below:

    Kafka 服务器支持监听多个端口上的连接。这是通过服务器配置中的 listeners 属性配置的,该属性接受要启用的以逗号分隔的 listener 列表。每个服务器上必须至少定义一个监听器。监听器中定义的每个监听器的格式如下所示:

{LISTENER_NAME}://{hostname}:{port}

原文引用:The LISTENER_NAME is usually a descriptive name which defines the purpose of the listener. For example, many configurations use a separate listener for client traffic, so they might refer to the corresponding listener as CLIENT in the configuration:

    LISTENER_NAME 通常是一个描述性名称,用于定义监听器的用途。例如,许多配置对客户端传输使用单独的监听器,因此它们可能会在配置中将相应的监听器称为 CLIENT:

listeners=CLIENT://localhost:9092

原文引用:The security protocol of each listener is defined in a separate configuration: listener.security.protocol.map. The value is a comma-separated list of each listener mapped to its security protocol. For example, the follow value configuration specifies that the CLIENT listener will use SSL while the BROKER listener will use plaintext.

    每个监听器的安全协议都在一个单独的配置中定义:listener.security.protocol.map。该值是映射到其安全协议的每个监听器的逗号分隔列表。例如,下面的值配置指定 CLIENT 监听器将使用SSL,而 BROKER 监听器将使用明文。

listener.security.protocol.map=CLIENT:SSL,BROKER:PLAINTEXT

原文引用:Possible options (case-insensitive) for the security protocol are given below:

  1. PLAINTEXT
  2. SSL
  3. SASL_PLAINTEXT
  4. SASL_SSL

安全协议的可能选项(不区分大小写)如下所示:

  1. PLAINTEXT(明文)
  2. SSL
  3. SASL_PLAINTEXT
  4. SASL_SSL

原文引用:The plaintext protocol provides no security and does not require any additional configuration. In the following sections, this document covers how to configure the remaining protocols.

    PLAINTEXT 协议不提供任何安全性,也不需要任何额外的配置。在以下各节中,本文档介绍了如何配置其余协议。

原文引用:If each required listener uses a separate security protocol, it is also possible to use the security protocol name as the listener name in listeners. Using the example above, we could skip the definition of the CLIENT and BROKER listeners using the following definition:

    如果每个必需的监听器都使用单独的安全协议,那么也可以使用安全协议名称作为监听器中的监听器名称。使用上面的示例,我们可以使用以下定义跳过 CLIENT 和 BROKER 监听器的定义:

listeners=SSL://localhost:9092,PLAINTEXT://localhost:9093

原文引用:However, we recommend users to provide explicit names for the listeners since it makes the intended usage of each listener clearer.

    但是,我们建议用户为监听器提供明确的名称,因为这会使每个监听器的预期用途更加清晰。

原文引用:Among the listeners in this list, it is possible to declare the listener to be used for inter-broker communication by setting the inter.broker.listener.name configuration to the name of the listener. The primary purpose of the inter-broker listener is partition replication. If not defined, then the inter-broker listener is determined by the security protocol defined by security.inter.broker.protocol, which defaults to PLAINTEXT.

    在该列表中的监听器中,可以通过将 inter.broker.listener.name 配置设置为监听器的名称来声明要用于 Broker 间通信的监听器。Broker 间监听器的主要用途是分区复制。如果未定义,则由security.inter.broker.procol 定义的安全协议来确定 Broker 间监听器,该协议默认为 PLAINTEXT。

原文引用:For legacy clusters which rely on Zookeeper to store cluster metadata, it is possible to declare a separate listener to be used for metadata propagation from the active controller to the brokers. This is defined by control.plane.listener.name. The active controller will use this listener when it needs to push metadata updates to the brokers in the cluster. The benefit of using a control plane listener is that it uses a separate processing thread, which makes it less likely for application traffic to impede timely propagation of metadata changes (such as partition leader and ISR updates). Note that the default value is null, which means that the controller will use the same listener defined by inter.broker.listener

    对于依赖 ZooKeeper 存储集群元数据的遗留集群,可以声明一个单独的监听器用于从活动控制器到 Broker 的元数据传播。这是由 control.plane.listener.name 定义的。当活动控制器需要将元数据更新推送到集群中的 Broker 时,它将使用此监听器。使用 control plane 监听器的好处是它使用了一个单独的处理线程,这使得应用程序传输不太可能阻碍元数据更改(如分区前导和 ISR 更新)的及时传播。请注意,默认值为 null,这意味着控制器将使用 inter.broker.listener 定义的同一个监听器。

原文引用:In a KRaft cluster, a broker is any server which has the broker role enabled in process.roles and a controller is any server which has the controller role enabled. Listener configuration depends on the role. The listener defined by inter.broker.listener.name is used exclusively for requests between brokers. Controllers, on the other hand, must use separate listener which is defined by the controller.listener.names configuration. This cannot be set to the same value as the inter-broker listener.

    在 KRaft 集群中,Broker 是在 process.roles 中启用 Broker 角色的任何服务器,控制器是启用控制器角色的任意服务器。监听器配置取决于角色。inter.broker.listener.name 定义的监听器专门用于 Broker 之间的请求。另一方面,控制器必须使用由 controller.listener.names 配置定义的独立监听器。不能将其设置为与 Broker 间监听器相同的值。

原文引用:Controllers receive requests both from other controllers and from brokers. For this reason, even if a server does not have the controller role enabled (i.e. it is just a broker), it must still define the controller listener along with any security properties that are needed to configure it. For example, we might use the following configuration on a standalone broker:

    控制器接收来自其他控制器和 Broker 的请求。因此,即使服务器没有启用控制器角色(即它只是一个 Broker),它仍然必须定义控制器监听器以及配置它所需的任何安全属性。例如,我们可以在独立 Broker 上使用以下配置:

process.roles=broker
listeners=BROKER://localhost:9092
inter.broker.listener.name=BROKER
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL

原文引用:The controller listener is still configured in this example to use the SASL_SSL security protocol, but it is not included in listeners since the broker does not expose the controller listener itself. The port that will be used in this case comes from the controller.quorum.voters configuration, which defines the complete list of controllers.

    在本例中,控制器 listener 仍然配置为使用 SASL_SSL 安全协议,但由于 Broker 不公开控制器listener 本身,因此它未包含在 listener 中。在这种情况下将使用的端口来自controller.quorum.voters 配置,该配置定义了控制器的完整列表。

原文引用:For KRaft servers which have both the broker and controller role enabled, the configuration is similar. The only difference is that the controller listener must be included in listeners:

    对于同时启用了 Broker 和控制器角色的 KRaft 服务器,配置是相似的。唯一的区别是控制器 listener 必须包含在 listener 中:

process.roles=broker,controller
listeners=BROKER://localhost:9092,CONTROLLER://localhost:9093
inter.broker.listener.name=BROKER
controller.quorum.voters=0@localhost:9093
controller.listener.names=CONTROLLER
listener.security.protocol.map=BROKER:SASL_SSL,CONTROLLER:SASL_SSL

原文引用:It is a requirement for the port defined in controller.quorum.voters to exactly match one of the exposed controller listeners. For example, here the CONTROLLER listener is bound to port 9093. The connection string defined by controller.quorum.voters must then also use port 9093, as it does here.

    要求 controller.quorum.voters 中定义的端口与一个公开的控制器 listener 完全匹配。例如,这里 CONTROLLER listener 绑定到端口 9093。controller.quorum.voters 定义的连接字符串也必须使用端口 9093,就像这里所做的那样。

原文引用:The controller will accept requests on all listeners defined by controller.listener.names. Typically there would be just one controller listener, but it is possible to have more. For example, this provides a way to change the active listener from one port or security protocol to another through a roll of the cluster (one roll to expose the new listener, and one roll to remove the old listener). When multiple controller listeners are defined, the first one in the list will be used for outbound requests.

    控制器将接受 controller.listener.names 定义的所有 listener上的请求。通常只有一个控制器 listener,但也可以有更多的 listener。例如,这提供了一种将活动 listener 从一个端口或安全协议更改为另一个端口的方法,通过集群的滚动(一个滚动用于公开新 listener,另一个滚动则用于删除旧 listener)。当定义了多个控制器 listener 时,列表中的第一个 listener 将用于出站请求。

原文引用:It is conventional in Kafka to use a separate listener for clients. This allows the inter-cluster listeners to be isolated at the network level. In the case of the controller listener in KRaft, the listener should be isolated since clients do not work with it anyway. Clients are expected to connect to any other listener configured on a broker. Any requests that are bound for the controller will be forwarded as described below 

    在 Kafka 中,为客户端使用单独的 listener 是一种传统做法。这允许在网络级别隔离集群间 listener。在 KRaft 中的控制器 listener 的情况下,应该隔离 listener,因为客户端无论如何都不使用它。客户端应连接到 Broker 上配置的任何其他 listener。绑定到控制器的任何请求都将按如下所述进行转发。

原文引用:In the following section, this document covers how to enable SSL on a listener for encryption as well as authentication. The subsequent section will then cover additional authentication mechanisms using SASL.

    在以下部分中,本文档介绍如何在 listener 上启用 SSL 以进行加密和身份验证。随后的部分将介绍使用 SASL 的其他身份验证机制。

这篇关于Kafka 安全之概览和监听器配置的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1063453

相关文章

Zookeeper安装和配置说明

一、Zookeeper的搭建方式 Zookeeper安装方式有三种,单机模式和集群模式以及伪集群模式。 ■ 单机模式:Zookeeper只运行在一台服务器上,适合测试环境; ■ 伪集群模式:就是在一台物理机上运行多个Zookeeper 实例; ■ 集群模式:Zookeeper运行于一个集群上,适合生产环境,这个计算机集群被称为一个“集合体”(ensemble) Zookeeper通过复制来实现

CentOS7安装配置mysql5.7 tar免安装版

一、CentOS7.4系统自带mariadb # 查看系统自带的Mariadb[root@localhost~]# rpm -qa|grep mariadbmariadb-libs-5.5.44-2.el7.centos.x86_64# 卸载系统自带的Mariadb[root@localhost ~]# rpm -e --nodeps mariadb-libs-5.5.44-2.el7

hadoop开启回收站配置

开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。 开启回收站功能参数说明 (1)默认值fs.trash.interval = 0,0表示禁用回收站;其他值表示设置文件的存活时间。 (2)默认值fs.trash.checkpoint.interval = 0,检查回收站的间隔时间。如果该值为0,则该值设置和fs.trash.interval的参数值相等。

NameNode内存生产配置

Hadoop2.x 系列,配置 NameNode 内存 NameNode 内存默认 2000m ,如果服务器内存 4G , NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列,配置 Nam

wolfSSL参数设置或配置项解释

1. wolfCrypt Only 解释:wolfCrypt是一个开源的、轻量级的、可移植的加密库,支持多种加密算法和协议。选择“wolfCrypt Only”意味着系统或应用将仅使用wolfCrypt库进行加密操作,而不依赖其他加密库。 2. DTLS Support 解释:DTLS(Datagram Transport Layer Security)是一种基于UDP的安全协议,提供类似于

【Python编程】Linux创建虚拟环境并配置与notebook相连接

1.创建 使用 venv 创建虚拟环境。例如,在当前目录下创建一个名为 myenv 的虚拟环境: python3 -m venv myenv 2.激活 激活虚拟环境使其成为当前终端会话的活动环境。运行: source myenv/bin/activate 3.与notebook连接 在虚拟环境中,使用 pip 安装 Jupyter 和 ipykernel: pip instal

搭建Kafka+zookeeper集群调度

前言 硬件环境 172.18.0.5        kafkazk1        Kafka+zookeeper                Kafka Broker集群 172.18.0.6        kafkazk2        Kafka+zookeeper                Kafka Broker集群 172.18.0.7        kafkazk3

客户案例:安全海外中继助力知名家电企业化解海外通邮困境

1、客户背景 广东格兰仕集团有限公司(以下简称“格兰仕”),成立于1978年,是中国家电行业的领军企业之一。作为全球最大的微波炉生产基地,格兰仕拥有多项国际领先的家电制造技术,连续多年位列中国家电出口前列。格兰仕不仅注重业务的全球拓展,更重视业务流程的高效与顺畅,以确保在国际舞台上的竞争力。 2、需求痛点 随着格兰仕全球化战略的深入实施,其海外业务快速增长,电子邮件成为了关键的沟通工具。

安全管理体系化的智慧油站开源了。

AI视频监控平台简介 AI视频监控平台是一款功能强大且简单易用的实时算法视频监控系统。它的愿景是最底层打通各大芯片厂商相互间的壁垒,省去繁琐重复的适配流程,实现芯片、算法、应用的全流程组合,从而大大减少企业级应用约95%的开发成本。用户只需在界面上进行简单的操作,就可以实现全视频的接入及布控。摄像头管理模块用于多种终端设备、智能设备的接入及管理。平台支持包括摄像头等终端感知设备接入,为整个平台提

2024网安周今日开幕,亚信安全亮相30城

2024年国家网络安全宣传周今天在广州拉开帷幕。今年网安周继续以“网络安全为人民,网络安全靠人民”为主题。2024年国家网络安全宣传周涵盖了1场开幕式、1场高峰论坛、5个重要活动、15场分论坛/座谈会/闭门会、6个主题日活动和网络安全“六进”活动。亚信安全出席2024年国家网络安全宣传周开幕式和主论坛,并将通过线下宣讲、创意科普、成果展示等多种形式,让广大民众看得懂、记得住安全知识,同时还