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

本文主要是介绍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:

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:
SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0
SASL/PLAIN - starting at version 0.10.0.0
SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0
SASL/OAUTHBEARER - starting at version 2.0
Authentication of connections from brokers to ZooKeeper
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.)
Authorization of read / write operations by clients
Authorization is pluggable and integration with external authorization services is supported

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

使用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版开始
从 Broker 到 ZooKeeper 的连接验证。
使用 SSL 对 Broker 和客户端之间、Broker 之间或 Broker 和工具之间传输的数据进行加密（请注意，启用 SSL 时会出现性能下降，其大小取决于 CPU 类型和 JVM 实现）。
客户端对读/写操作的授权。
授权是可插拔的，并且支持与外部授权服务集成。

原文引用：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:

PLAINTEXT
SSL
SASL_PLAINTEXT
SASL_SSL

安全协议的可能选项（不区分大小写）如下所示：

PLAINTEXT（明文）
SSL
SASL_PLAINTEXT
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 安全之概览和监听器配置的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！