kafka安全性

本文概述

• Kafka安全的需要
• Kafka Security的组件
• 安全模式

可能有几个消费者可以从Kafka读取数据，而生产者可以产生数据。但是，还必须确保数据的安全性。

Kafka安全的需要

有某些原因描述了对安全性的需求：

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

Kafka Security的组件

Kafka Security主要包含三个主要组件：

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

安全模式

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

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

不同的SASL机制是：

GSSAPI（Kerberos）：如果已经使用Kerberos服务器或Active Directory，则不需要仅为Kafka安装新服务器。

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

SCRAM：它扩展了“盐分挑战响应认证机制”。它是SASL机制的一个家族，它通过执行用户名/密码身份验证（例如PLAIN）来解决安全问题。卡夫卡中的SCRAM将其凭据保存在zookeeper中，可进一步用于卡夫卡安装。

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

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

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