我们知道消费者可以从Kafka中读取数据,而生产者则可以生产数据。但是要确保数据的安全性。 Kafka安全的需要可以有多个读取数据的消费者。在有些情况下,用户希望和一个或两个特定的消费者分享数据。因此,需要确保数据不受其他消费者的影响。 消费者被允许向任何主题写入数据/消息。因此,任何不需要的消费者有可能破坏用户已有的消费者。这是灾难性的,需要授权安全。 任何未经授权的用户也有可能从用户集群中删除任何主题。
Kafka安全组件Kafka安全有三个主要部分: 加密(Encryption)。Kafka Broker和客户端之间的数据交换是通过加密来保证安全的。Kafka加密确保没有其他客户端可以拦截并窃取或读取数据。数据只以加密的格式共享。 认证(Authentication)。这确保了各种应用程序与Kafka Broker的连接。只有被授权的应用程序才能够发布或消费消息。被授权的应用程序有各自的用户ID和密码来访问集群中的消息。 授权(Authorization)。这是在认证之后。当客户端被认证后,它被允许发布或消费消息。应用程序也可以被限制写访问,以防止数据污染。
安全模型Kafka有以下安全模型: PLAINTEXT:一般来说,数据是以字符串形式发送到Kafka的。PLAINTEXT不需要任何认证和授权。因此,数据不安全。PLAINTEXT只适用于“概念验证”。因此,不建议使用在较高数据安全性的环境中。 SSL:它是”安全套接字层“的扩展。SSL既可用于加密,也可用于认证。如果任何应用程序使用SSL,需要对其进行配置。SSL加密允许单向认证,允许客户端认证服务器证书。SSL认证允许双向认证,Broker也可以认证客户端的证书。但是,由于加密的开销,启用SSL会影响性能。 SASL: 它是”安全认证和安全层“的扩展。它是一个用于互联网上数据安全和用户认证的框架。Apache Kafka通过SASL实现客户端认证。许多SASL机制都是在Broker上启用的,但客户只能选择一种机制。
SASL机制有许多类型GSSAPI(Kerberos): 如果已经在使用Kerberos服务器或活动目录,就不需要为Kafka安装一个新的服务器。 PLAIN: 这是一种简单的传统安全方法,使用有效的用户名和密码作为认证机制。在Kafka中,PLAIN 是默认实现。它可以进一步扩展,以便在生产环境使用Kafka。SASL/PLAIN应该作为一个传输层来使用,以确保明确的密码不会在没有加密的情况下通过电线传输。 SCRAM: 它扩展了"Salted Challenge Response Authentication Mechanism"。它是SASL机制的一个系列,通过执行用户名/密码认证来解决安全问题,如PLAIN。Kafka中的SCRAM将其证书保存在zookeeper中,这可以进一步用于Kafka的安装。 OUATHBEARER: OUATH2授权框架允许第三方应用程序在限制中访问HTTP服务。Kafka中默认的OAUTHBEARER适合用于Apache Kafka的非生产环境安装。此外,它还创建以及验证不安全的JSON web token。 Delegation Tokens: 它是一种轻量级的认证机制,用于完成SASL/SSL方法。授权令牌在Kafka Borker和客户端之间的共享密钥。这些令牌帮助框架在安全的环境下将工作负载分配给可用的工作者。同时,不需要额外的分发成本。
结论通过加密、认证和授权,给数据开启了Kafka安全。 |