内容
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,那就会破坏安全性。