Kafka 安全性

Kafka 可以有多个消费者从 Kafka 读取数据，也有生产者生产数据。但是，确保数据安全也是必要的。

Kafka 安全的需求

有一些原因说明了安全的需求

1. 可以有多个消费者读取数据。有时用户只想与一个或两个特定消费者共享数据。因此，数据需要对其他消费者保密。
2. 消费者被允许向任何主题写入数据/消息。因此，任何不受欢迎的消费者都可能破坏用户已有的消费者。这是灾难性的，需要授权安全。
3. 还可能任何未经授权的用户从用户集群中删除任何主题。

Kafka 安全组件

Kafka 安全主要有三个主要组件

1. 加密：Kafka Broker 和客户端之间的数据交换通过加密来保证安全。Kafka 加密确保没有其他客户端可以拦截、窃取或读取数据。数据将仅以加密格式共享。
2. 身份验证：这确保了各种应用程序与 Kafka Broker 的连接。只有获得授权的应用程序才能发布或消费消息。授权应用程序将拥有其相应的用户 ID 和密码来访问集群中的消息。
3. 授权：这是在身份验证之后进行的。当客户端通过身份验证后，它就可以发布或消费消息。应用程序也可以被限制写入访问，以防止数据污染。

安全模型

以下是 Apache Kafka 中使用的安全模型

1. PLAINTEXT：通常，数据以字符串形式发送到 Kafka。PLAINTEXT 不需要任何身份验证和授权。因此，数据不安全。PLAINTEXT 仅用于“概念验证”。因此，不推荐用于需要高数据安全性的环境。
2. SSL：它代表“安全套接字层”。SSL 可用于加密和身份验证。如果任何应用程序使用 SSL，则需要对其进行配置。SSL 加密允许单向身份验证，该身份验证允许客户端验证服务器证书。SSL 身份验证允许双向身份验证，其中 Broker 还可以验证客户端证书。但是，启用 SSL 可能会因加密开销而影响性能。
3. SASL：它代表“安全身份验证和安全层”。它是互联网上的数据安全和用户身份验证的框架。Apache Kafka 通过 SASL 启用客户端身份验证。Broker 上可能同时启用了多个 SASL 机制，但客户端只能选择一种机制。

不同的 SASL 机制是

GSSAPI(Kerberos)：如果已经在使用 Kerberos 服务器或 Active Directory，则无需单独为 Kafka 安装新服务器。

PLAIN：这是一种简单的传统安全方法，它使用有效的用户名和密码作为身份验证机制。在 Kafka 中，PLAIN 是默认实现。它可以进一步扩展用于 Kafka 中的生产环境。SASL/PLAIN 应用于传输层，以确保未加密的密码不会在网络上传输。

SCRAM：它代表“加盐挑战响应身份验证机制”。它是一系列 SASL 机制，通过执行用户名/密码身份验证来解决安全问题，就像 PLAIN 所做的那样。Kafka 中的 SCRAM 将其凭证保存在 zookeeper 中，这些凭证可用于 Kafka 安装。

OUATHBEARER：OUATH2 授权框架允许第三方应用程序在有限范围内访问 HTTP 服务。Kafka 中的默认 OAUTHBEARER 适用于 Apache Kafka 的非生产安装。此外，它还会创建和验证未签名的 JSON Web 令牌。

委托令牌：这是一种轻量级的身份验证机制，用于完成 SASL/SSL 方法。委托令牌充当 Kafka Broker 和客户端之间的共享密钥。这些令牌有助于框架在安全的环境中将工作负载分发给可用的工作节点。此外，不需要额外的分发成本。

因此，通过加密、身份验证和授权，可以为数据启用 Kafka 安全。