基于 SASL/SCRAM 让 Kafka 实现动态授权认证

一、说明

在大数据处理和分析中 Apache Kafka 已经成为了一个核心组件。然而在生产环境中部署 Kafka 时，安全性是一个必须要考虑的重要因素。SASL（简单认证与安全层）和 SCRAM（基于密码的认证机制的盐化挑战响应认证机制）提供了一种方法来增强 Kafka 集群的安全性。

本文将从零开始部署 ZooKeeper 和 Kafka 并通过配置 SASL/SCRAM 和 ACL（访问控制列表）来增强 Kafka 的安全性。

 

二、Kafka 的安全机制

kafka 社区在 0.9.0.0 版本正式添加了安全特性，可以满足各种安全性的要求，包括：

1. Kafka 与 ZooKeeper 之间的安全通信；
2. Kafka 集群 ZooKeeper 之间的安全通信；
3. 客户端与服务端之间的安全通信；
4. 消息级别的权限控制，可以控制客户端（生产者或消费者）的读写操作权限。

 

认证方式	引入版本	适用场景
SSL	0.9.0	SSL做信道加密比较多，SSL认证不如SASL所以一般都会使用SSL来做通信加密。
SASL/GSSAPI	0.9.9	主要是给 Kerberos 使用的。如果你的公司已经做了 Kerberos 认证（比如使用 Active Directory），那么使用 GSSAPI 是最方便的了。因为你不需要额外地搭建 Kerberos，只要让你们的 Kerberos 管理员给每个 Broker 和要访问 Kafka 集群的操作系统用户申请 principal 就好了。
SASL/PLAIN	0.10.2	简单的用户名密码认证，通常与SSL结合使用，对于小公司来说，没必要搭建公司级别的Kerberos，使用它就比较合适。
SASL/SCRAM	0.10.2	PLAIN的加强版本，支持动态的用户增减。
Deleation Token	1.1	Delegation Token 是在 1.1 版本引入的，它是一种轻量级的认证机制，主要目的是补充现有的 SASL 或 SSL 认证。如果要使用 Delegation Token，你需要先配置好 SASL 认证，然后再利用 Kafka 提供的 API 去获取对应的 Delegation Token。这样 Broker 和客户端在做认证的时候，可以直接使用这个 token，不用每次都去 KDC 获取对应的 ticket（Kerberos 认证）或传输 Keystore 文件（SSL 认证）。
SASL/OAUTHBEARER	2.0	OAuth 2框架的集成。

 

三、环境和软件准备

从 Apache Kafka 官网 下载对应版本的 Kafka 并解压到你选择的目录。

确保已经安装 Java 才能运行 Kafka，可以通过运行 java -version 来检查 Java 环境。

 

四、部署 Zookeeper

使用 Kafka 内置的 Zookeeper

4.1. 启用 SASL 认证

进入 config 目录，修改 zookeeper.properties 配置文件增加以下内容：

authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
jaasLoginRenew=3600000
requireClientAuthScheme=sasl
zookeeper.sasl.client=true

 

4.2. 配置 JAAS

在 config 目录下创建 zk_jaas.conf 文件，内容如下：

Server {
   
    org.apache.zookeeper.server.auth.DigestLoginModule required
    username="admin"
    password="admin"
    user_admin="admin"
    user_zkclient="zkclient";
};
<