Kafka安全

我们知道消费者可以从Kafka中读取数据，而生产者则可以生产数据。但是要确保数据的安全性。

Kafka安全的需要

1. 可以有多个读取数据的消费者。在有些情况下，用户希望和一个或两个特定的消费者分享数据。因此，需要确保数据不受其他消费者的影响。
2. 消费者被允许向任何主题写入数据/消息。因此，任何不需要的消费者有可能破坏用户已有的消费者。这是灾难性的，需要授权安全。
3. 任何未经授权的用户也有可能从用户集群中删除任何主题。

Kafka安全组件

Kafka安全有三个主要部分：

1. 加密（Encryption）。Kafka Broker和客户端之间的数据交换是通过加密来保证安全的。Kafka加密确保没有其他客户端可以拦截并窃取或读取数据。数据只以加密的格式共享。
2. 认证（Authentication）。这确保了各种应用程序与Kafka Broker的连接。只有被授权的应用程序才能够发布或消费消息。被授权的应用程序有各自的用户ID和密码来访问集群中的消息。
3. 授权（Authorization）。这是在认证之后。当客户端被认证后，它被允许发布或消费消息。应用程序也可以被限制写访问，以防止数据污染。

安全模型

Kafka有以下安全模型：

1. PLAINTEXT：一般来说，数据是以字符串形式发送到Kafka的。PLAINTEXT不需要任何认证和授权。因此，数据不安全。PLAINTEXT只适用于“概念验证”。因此，不建议使用在较高数据安全性的环境中。
2. SSL：它是”安全套接字层“的扩展。SSL既可用于加密，也可用于认证。如果任何应用程序使用SSL，需要对其进行配置。SSL加密允许单向认证，允许客户端认证服务器证书。SSL认证允许双向认证，Broker也可以认证客户端的证书。但是，由于加密的开销，启用SSL会影响性能。
3. SASL： 它是”安全认证和安全层“的扩展。它是一个用于互联网上数据安全和用户认证的框架。Apache Kafka通过SASL实现客户端认证。许多SASL机制都是在Broker上启用的，但客户只能选择一种机制。

SASL机制有许多类型

1. GSSAPI(Kerberos)： 如果已经在使用Kerberos服务器或活动目录，就不需要为Kafka安装一个新的服务器。
2. PLAIN： 这是一种简单的传统安全方法，使用有效的用户名和密码作为认证机制。在Kafka中，PLAIN 是默认实现。它可以进一步扩展，以便在生产环境使用Kafka。SASL/PLAIN应该作为一个传输层来使用，以确保明确的密码不会在没有加密的情况下通过电线传输。
3. SCRAM： 它扩展了"Salted Challenge Response Authentication Mechanism"。它是SASL机制的一个系列，通过执行用户名/密码认证来解决安全问题，如PLAIN。Kafka中的SCRAM将其证书保存在zookeeper中，这可以进一步用于Kafka的安装。
4. OUATHBEARER： OUATH2授权框架允许第三方应用程序在限制中访问HTTP服务。Kafka中默认的OAUTHBEARER适合用于Apache Kafka的非生产环境安装。此外，它还创建以及验证不安全的JSON web token。
5. Delegation Tokens： 它是一种轻量级的认证机制，用于完成SASL/SSL方法。授权令牌在Kafka Borker和客户端之间的共享密钥。这些令牌帮助框架在安全的环境下将工作负载分配给可用的工作者。同时，不需要额外的分发成本。

结论

通过加密、认证和授权，给数据开启了Kafka安全。

参考

https://kafka.apache.org/10/documentation/streams/developer-guide/security.html

原文标题：Kafka Security
原文作者：Jatin
原文地址：https://blog.knoldus.com/kafka-security/