Kafka安全机制详解（认证、鉴权、配置、代码示例）

原创

于 2025-04-21 09:30:00 发布 · 置顶 · 2.1k 阅读

38 ·

CC 4.0 BY-SA版权

文章标签：

#kafka #安全 #分布式

概述

本文以Kafka_2.13-2.18版本为示例，配合 Zookeeper，全面的讲解与Kafak安全机制相关的认证、鉴权、配置、C++/Python/Java代码示例

名词解释

SASL, Simple Authentication and Security Layer,是一种用于身份认证的框架，定义了统一接口，支持多种认证机制，常见的有：

PLAIN 明文用户名/密码（需要配合 TLS 使用）
SCRAM 使用哈希算法（SHA-256/512）保护密码
GSSAPI 基于 Kerberos 的认证机制
OAUTHBEARER OAuth2 令牌认证 ANONYMOUS
匿名身份（通常不建议用于生产）

SSL, Secure Socket Layer, 已经被TLS取代了，是一种加密协议，用于在网络中建立安全通信通,主要用于：

加密通信内容，防止数据被中间人窃听。
身份验证（可选）：服务器或客户端可提供证书，验证彼此身份。
数据完整性：确保数据传输过程中不被篡改。

PLAINTEXT 是security.protocol的协议之一，只使用明文通信，不做任何加密，也不启用 SASL认证，一般用于内部测试。
SASL_PLAINTEXT 是 security.protocol的协议之一，有认证，但传输是明文的，是 SASL的一种
SASL_SSL 是 security.protocol的协议之一，有认证，传输内容经过 SSL(TLS)加密，是SASL的一种
ACL 是 Access Control List的简写，控制权限列表
JAAS，是Java Authentication and Authorization Service的简写，是一种配置文件。

认证与鉴权

Kafka 2.1+支持多种认证机制，包括客户端(producer/consumer)和broker之间，当然也包含 brokers之间。
认证与鉴权是分离的两种完全不相干的机制，共同配置完成了认证与权限的控制。

认证

SASL

SASL 是个统一框架，它支持多种认证机制：
在这里插入图片描述
你现在列出的是 Kafka（或者其他支持 SASL 协议的系统）中常见的几种 SASL认证机制：

🧩 SASL 是个统一框架，它支持多种认证机制：

SASL机制	作用	加密需求	安全性	推荐等级
`PLAIN`	明文用户名/密码认证	✅ 需要搭配 SSL	⚠️ 中等（需加密通道）	⭐⭐
`SCRAM`	基于哈希（SHA）认证	❌ 可不加密但建议加密	✅ 较高	⭐⭐⭐⭐
`GSSAPI`	使用 Kerberos（企业域）认证	❌（协议本身不加密）	✅ 很高	⭐⭐⭐⭐⭐
`OAUTHBEARER`	使用 OAuth 2.0 令牌认证	✅（通常走 HTTPS）	✅ 高	⭐⭐⭐⭐

🔐 SASL/PLAIN

✅ 特点：

最简单的机制：用户名+密码。
密码明文传输（所以需要搭配 SASL_SSL 或 SSL 加密）。
Kafka 服务器端需配置 JAAS 文件或在配置中显式声明用户密码。

🚫 安全风险：

如果只用 SASL_PLAINTEXT，密码将以明文形式传输。

🔐SASL/SCRAM

✅ SCRAM（Salted Challenge Response Authentication Mechanism）

是对 PLAIN 的安全升级版，使用哈希算法 + 盐 + 认证握手，不会直接传输密码。
支持：SCRAM-SHA-256 和 SCRAM-SHA-512

📌 Kafka 配置支持：

Kafka 需在服务端启用 SCRAM 用户，并使用 Kafka 内建的 kafka-configs.sh 工具添加用户名和密码。

kafka-configs.sh --alter --add-config 'SCRAM-SHA-256=[iterations=4096,password=123456]' \
--entity-type users --entity-name alice --bootstrap-server localhost:9092

🔐 SASL/GSSAPI

✅ Kerberos 企业级认证（最安全，但最复杂）

基于 Kerberos 协议，通常用于大公司内网、企业集群。
用户和服务都由 KDC（Key Distribution Center）进行认证。
Kafka 配置需指定 principal 和 keytab 文件。

📌 适用场景：

企业级环境，有现成 Kerberos 服务器。
Hadoop 集群、Kerberized Kafka。

🔐 SASL/OAUTHBEARER

✅ OAuth 2.0 令牌认证（现代 Web 常用方式）

Kafka 客户端使用 OAuth 令牌进行认证。
需配合 OAuth 提供者（如 Keycloak、Auth0、Google、Azure AD）配置。
服务端需实现 oauthbearer 认证回调接口。

📌 适用场景：

Kafka 与微服务架构集成，集中身份认证。
支持动态权限管理。

鉴权

Kafka 的 ACL（Access Control List）是 Kafka 提供的一套权限控制机制，用于限制哪些用户/客户端能访问哪些资源（topic、group、cluster 等），以保障 Kafka 集群的安全性。

📌 一、Kafka ACL 是什么？

Kafka 的 ACL 是基于 资源（Resource）+ 操作（Operation）+ 主体（Principal） 三者绑定的权限系统。

资源类型：Topic、Group、Cluster、TransactionalId、User
操作：Read、Write、Create、Delete、Describe、Alter、All
主体（Principal）：如 "User:alice"

🧩 二、Kafka ACL 示例结构

Kafka 的 ACL 规则长这样：

用户 (Principal) 对资源 (Resource) 拥有 某种操作权限 (Operation)

例如：

User:alice 允许读取 Topic:payments

🛠 三、命令操作：创建、查看、删除 ACL

Kafka 提供 kafka-acls.sh 脚本来管理 ACL：

✅ 添加 ACL

# 允许用户 alice 对 topic test 拥有读权限
kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 \
  --add --allow-principal "User:alice" \
  --operation Read --topic test

也可以添加写权限：

# 允许写 topic test
kafka-acls.sh --add --allow-principal "User:alice" \
  --operation Write --topic test

或允许某个 group 使用：

# 允许用户 alice 订阅 group1
kafka-acls.sh --add --allow-principal "User:alice" \
  --operation Read --group group1

✅ 查看 ACL

# 查看所有 ACL
kafka-acls.sh --list --authorizer-properties zookeeper.connect=localhost:2181

# 查看某个用户的 ACL
kafka-acls.sh --list --principal User:alice \
  --authorizer-properties zookeeper.connect=localhost:2181