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 能够处理后台任务或充当微服务之间 ...