Kafka 安全 Security

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

需要Kafka安全

有一些原因描述了安全的需要:

可以有多个消费者读取数据。在某些情况下，用户希望与一两个特定的消费者共享数据。因此，需要保护数据不被其他消费者使用。
消费者可以向任何主题写入数据/消息。因此，任何不需要的消费者都有可能破坏用户已经存在的消费者。这是灾难性的，需要授权安全。
任何未经授权的用户也可能从用户集群中删除任何主题。

Kafka Security 的组成部分

Kafka Security 主要包括三个主要组成部分:

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

安全模型

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

PLAINTEXT: 通常，数据以字符串形式发送到 Kafka。 PLAINTEXT 不需要任何身份验证和授权。因此，数据是不安全的。 PLAINTEXT 仅用于"概念验证"。因此，对于数据安全性要求较高的环境，不推荐使用。
SSL: 它扩展为"安全套接字层"。 SSL 可用于加密和身份验证。如果任何应用程序正在使用 SSL，则需要对其进行配置。 SSL 加密允许 1 向身份验证，允许客户端对服务器证书进行身份验证。SSL 身份验证允许 2 向身份验证，其中代理也可以对客户端证书进行身份验证。但是，由于加密开销，启用 SSL 会影响性能。
SASL: 它扩展为"安全认证和安全层"。它是一个通过互联网实现数据安全和用户身份验证的框架。 Apache Kafka 通过 SASL 启用客户端身份验证。代理上一共启用了多种 SASL 机制，但客户端只需选择一种机制。

不同的 SASL 机制是:

GSSAPI(Kerberos): 如果 Kerberos 服务器或 Active Directory 已在使用中，则无需安装仅适用于 Kafka 的新服务器。

PLAIN: 这是一种简单的传统安全方法，它使用有效的用户名和密码作为身份验证机制。在 Kafka 中，PLAIN 是默认实现。它可以进一步扩展用于 Kafka 中的生产用途。 SASL/PLAIN 应该用作传输层，以确保在未加密的情况下不会通过线路传输明文密码。

SCRAM: 它扩展为 ?Salted Challenge Response Authentication机制？。它是一系列 SASL 机制，通过执行用户名/密码身份验证(如 PLAIN)来解决安全问题。 Kafka 中的 SCRAM 将其凭据保存在 zookeeper 中，可进一步用于 Kafka 安装。

OUATHBEARER: OUATH2 授权框架允许第三方应用程序访问 HTTP 服务一个限制。 Kafka 中的默认 OAUTHBEARER 适用于 Apache Kafka 的非生产安装。此外，它还创建和验证不安全的 JSON 网络令牌。

委托令牌: 它是一种用于完成 SASL/SSL 方法的轻量级身份验证机制。委托令牌作为 Kafka 经纪人和客户之间的共享秘密。这些令牌有助于框架将工作负载分配给安全环境中的可用工作人员。此外，不需要额外的分发成本。

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

下一章：Kafka 对比 RabbitMQ

Kafka Vs RabbitMQ：什么是RabbitMQ？RabbitMQ 是使用最广泛、通用和开源的消息代理。它于 2007 年发布，是消息传递系统中的主要组件。目前，它用于流式用例。 RabbitMQ 能够处理后台任务或充当微服务之间 ...

上一章：Kafka 消息压缩

下一章：Kafka 对比 RabbitMQ