内容
1. 引言
在本章中，我们将学习Apache Kafka 安全的概念，包括为什么需要安全性，加密介绍以及ZooKeeper身份验证。我们还将看到通过Kafka 安全可以轻松解决的问题列表。此外，我们将学习Kafka身份验证和授权，以及ZooKeeper的身份验证。
pic
2. Kafka安全介绍
Kafka社区版本0.9.0.0添加了许多功能，它们可以灵活使用，比如单独或一起使用，这些功能增强了Kafka集群的安全性。
pic
当前支持的安全措施列表如下：
1. 通过使用SSL或SASL，可以验证客户端与Kafka 代理的连接，其他工具也是如此。Kafka支持各种SASL机制：
-
SASL/GSSAPI (Kerberos) – 从0.9.0.0版本开始
-
SASL/PLAIN – 从0.10.0.0版本开始
-
SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 – 从0.10.2.0版本开始
2. 提供从代理到ZooKeeper的连接认证。
3. 它在代理和Kafka客户端之间或着代理和其他工具之间使用SSL对传输的数据进行加密，包括：
-
对客户端读/写操作的授权。
-
授权是可插拔的，并且还支持与外部授权服务的集成。
3. 为什么需要Kafka安全？
Apache Kafka扮演着内部中间层的角色，这使我们的后端系统能够通过Kafka主题彼此共享实时数据。通常，任何用户或应用程序都可以使用标准Kafka设置将任何消息写入任何主题，以及从任何主题读取数据。但是，当公司转向共享租赁模式而且多个团队和应用程序使用相同的Kafka集群时，或者当Kafka 集群开始用于处理某些关键和机密信息时，实施Kafka安全就很重要并且是必须的了。
4. Kafka安全解决的问题
Kafka 安全有三个组件：
a. 使用SSL/TLS加密正在传输的数据
它持续在生产者和Kafka代理之间以及消费者和Kafka代理之间对数据加密。而且，这是大家在上网时非常常见的模式。
b. 使用SSL或SASL进行认证（Authentication）
它允许生产者和消费者在连接Kafka集群是进行身份认证，以验证他们的身份。这是认证客户端身份的非常安全的方式，有助于授权。
c. 使用ACL做授权（Authorization）
Kafka代理可以针对访问控制列表（ACL）运行我们的客户端，来决定某个特定客户端是否有权写入或读取某个主题。
5. 加密（SSL）
pic
由于数据包会被路由到Kafka集群，以及从机器传送到另外的机器，加密解决了中间人攻击（MITM）的问题。如果我们的数据是明文文本，那么这些路由器中的任何一个都可以读取数据的内容。
通过启用加密并仔细设置SSL证书，数据在网络里被加密并被安全的传输。只有第一台和最后一台机器能通过SSL解密正在发送的数据。
注意：加密会增加系统的开销，不过相比安全来说，这点开销是值得的。加密仅在数据传输时进行，代理磁盘上的数据仍然未加密。
6. Kafka认证（Authentication）（SSL & SASL）
有两种方式对连接到Kafka代理的客户端进行认证：SSL 和SASL。
pic
a. SSL认证
它利用了SSL的功能，我们还称之为双向认证。证书颁发机构签署并向客户颁发证书，允许Kafka代理验证客户的身份。
这是最常见的设置，尤其是当我们利用Heroku，Confluent Cloud或CloudKarafka等提供商的提供的可管理的Kafka集群时。
b. SASL认证
SASL指的是简单授权服务层，它基本概念是认证机制和Kafka协议是彼此分离的，它在大数据系统和Hadoop中非常流行。
Kafka支持以下SASL形式：
i. SASL PLAINTEXT
SASL PLAINTEXT是一个经典的用户名/密码组合。我们需要提前在Kafka代理上存储这些用户名和密码，因为每次更改都需要触发重启。 这种形式的安全性较低，不推荐使用。 此外，请确保在使用SASL PLAINTEXT时启用SSL加密，以保证认证信息不会作为PLAINTEXT在网络上发送。
ii. SASL SCRAM
这是一个非常安全的组合。密码和Zookeeper哈希（Hash）存储在Zookeeper中，因此即使不重新启动代理也可以扩展安全性。确保在使用SASL SCRAM时启用SSL加密，因此认证信息不会作为PLAINTEXT在网络上发送。
iii. SASL GSSAPI (Kerberos)
它也是提供身份验证的一种非常安全的方法，因为它基于Kerberos机制。Kerberos最常见的实现是Microsoft Active Directory，它允许公司从他们的Kerberos服务器中做安全管理，因此SASL GSSAPI是大型企业的绝佳选择。但是，对Kafka使用Kerberos设置非常复杂，但最终还是值得的。
-
WIP SASL Extention (KIP-86 进行中)
我们使用它可以更容易的d配置未在Kafka中实现的新的或自定义的SASL机制。 -
(WIP) SASL OAUTHBEARER (KIP-255 进行中)
允许我们利用OAUTH2令牌进行身份验证。
7. Kafka授权（ACL）
一旦Kafka客户端通过身份验证，Kafka就需要决定他们能做什么和不能做什么。这就是授权的职责，由访问控制列表（ACL）控制。
由于ACL可以帮助我们预防灾难，因此它们非常有用。让我们通过一个例子来理解它：我们有一个主题（Topic），我们限定只能从一些客户端或主机写入，而且我们希望阻止普通用户为这些主题编入任何内容，ACL就可以帮助我们实现这些需求，从而防止任何数据损坏或反序列化错误。如果我们有一些敏感数据，ACL也能限制只有某些应用程序或用户才能访问这些数据。
kafka-acls命令可以帮助我们添加ACL，它甚至还有一些快捷方式来添加生产者或消费者。
kafka-acl --topic test --producer --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:alice
运行的结果将是：
Adding ACLs for resource `Topic:test`: User:alice has Allow permission for operations: Describe from hosts: * User:alice has Allow permission for operations: Write from hosts: * Adding ACLs for resource `Cluster:kafka-cluster`: User:alice has Allow permission for operations: Create from hosts: *
注意：只能用默认的SimpleAclAuthorizer在Zookeeper中存储ACL。另外，确保只有Kafka代理可以写入Zookeeper（zookeeper.set.acl = true），否则，如果任何用户都可以进入并编辑ACL，那就会破坏安全性。
