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