首页 > 编程语言 >Kafka KRaft模式启动的JAAS配置示例

Kafka KRaft模式启动的JAAS配置示例

来源：互联网 2026-07-18 08:08:09

在KRaft模式下配置KafkaSASL认证需创建JAAS文件，注意分号和用户名前缀；修改server.properties启用SASL/PLAIN，将JAAS路径加入启动脚本，格式化存储后启动；生产环境推荐使用SCRAM-SHA-512动态创建用户，并分配ACL权限以实现安全管控。

在 KRaft 模式下为 Kafka 配置 SASL 认证，是许多团队搭建安全环境时遇到的第一个技术门槛。认证配置本身并不复杂，但步骤较为零散，容易因遗漏细节导致认证失败——例如 JAAS 文件末尾忘记加分号，或启动脚本中未加载配置路径。本文按步骤拆解 Kafka KRaft SASL 认证配置流程，帮助开发者快速完成部署。

一、创建 JAAS 配置文件

文件路径：config/kafka_server_jaas.conf

长期稳定更新的攒劲资源： >>>点此立即查看<<<

KafkaServer {
    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_log_agent="gzagent#wn1WEE01"
    user_log_server="gzserver#wn1WEE02";
};

关键注意事项：

username 和 password 是 Broker 节点之间通信的管理员账户。在 KRaft 模式下，Controller 与 Broker 之间的通信同样依赖该账号。
user_<用户名> 用于客户端连接。前缀必须是 user_，后接具体的用户名。
分号 ; 必须保留——任何遗漏都会导致服务启动时报认证失败错误。
密码中的 # 为合法字符，无需转义处理。

二、修改 config/kraft/server.properties

Kafka KRaft 模式下，server.properties 文件需要同时配置 Broker 和 Controller 的通信参数，并启用 SASL 认证。

# ========== Broker 基础配置 ==========
node.id=1
controller.quorum.voters=1@localhost:9093
process.roles=broker,controller
listeners=SASL_PLAINTEXT://localhost:9092,CONTROLLER://localhost:9093
advertised.listeners=SASL_PLAINTEXT://localhost:9092
inter.broker.listener.name=SASL_PLAINTEXT
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,SASL_PLAINTEXT:SASL_PLAINTEXT
# ========== SASL 认证配置 ==========
sasl.enabled.mechanisms=PLAIN
sasl.mechanism.inter.broker.protocol=PLAIN
# ========== 授权配置（配合 ACL 使用） ==========
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:admin
# ========== 日志目录 ==========
log.dirs=/tmp/kraft-combined-logs

三、修改启动脚本，加载 JAAS 文件

文件：bin/kafka-server-start.sh

在文件开头（export KAFKA_HEAP_OPTS 附近）添加以下配置，确保 Kafka 启动时加载 JAAS 认证文件：

# 加载 JAAS 配置文件
export KAFKA_OPTS="-Dja va.security.auth.login.config=/path/to/kafka/config/kafka_server_jaas.conf"

请将 /path/to/kafka/ 替换为实际的 Kafka 安装路径，否则 JAAS 配置文件不会被加载。

四、格式化存储并启动 Kafka KRaft 节点

如果是首次启动 KRaft 模式，必须先执行格式化命令，否则节点无法加入集群：

# 加载 JAAS 配置文件
export KAFKA_OPTS="-Dja va.security.auth.login.config=/path/to/kafka/config/kafka_server_jaas.conf"

格式化命令：./bin/kafka-storage.sh format -t -c config/kraft/server.properties

五、创建用户并分配 SCRAM 凭证

服务启动后，可使用 kafka-configs.sh 动态创建用户并设置 SCRAM 密码。相比 PLAIN 机制，SCRAM 的密码不会明文传输，安全性更高：

# ========== 创建用户 log_agent（写权限）==========
bin/kafka-configs.sh --bootstrap-server localhost:9092 
  --alter 
  --add-config 'SCRAM-SHA-512=[password=gzagent#wn1WEE01]' 
  --entity-type users 
  --entity-name log_agent
# ========== 创建用户 log_server（读权限）==========
bin/kafka-configs.sh --bootstrap-server localhost:9092 
  --alter 
  --add-config 'SCRAM-SHA-512=[password=gzserver#wn1WEE02]' 
  --entity-type users 
  --entity-name log_server

如果仍使用 PLAIN 机制，可跳过此步骤——用户信息已在 kafka_server_jaas.conf 中定义，直接使用 user_log_agent 和 user_log_server 连接即可。但 PLAIN 的密码以明文传输，生产环境强烈建议改用 SCRAM-SHA-512。

六、分配 ACL 权限

创建用户后，需要为每个用户分配对应的 Topic 访问权限：

# 允许 log_agent 向 Topic 写入
bin/kafka-acls.sh --bootstrap-server localhost:9092 
  --add 
  --allow-principal User:log_agent 
  --operation Write 
  --topic my-private-topic
# 允许 log_server 从 Topic 读取
bin/kafka-acls.sh --bootstrap-server localhost:9092 
  --add 
  --allow-principal User:log_server 
  --operation Read 
  --topic my-private-topic 
  --group log-server-group

七、客户端连接配置

生产者（log_agent）

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("security.protocol", "SASL_PLAINTEXT");  // KRaft 单机可用 PLAINTEXT，生产建议 SASL_SSL
props.put("sasl.mechanism", "PLAIN");               // 或 "SCRAM-SHA-512"
props.put("sasl.jaas.config",
    "org.apache.kafka.common.security.plain.PlainLoginModule required " +
    "username="log_agent" password="gzagent#wn1WEE01";");

消费者（log_server）

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("security.protocol", "SASL_PLAINTEXT");
props.put("sasl.mechanism", "PLAIN");
props.put("sasl.jaas.config",
    "org.apache.kafka.common.security.plain.PlainLoginModule required " +
    "username="log_server" password="gzserver#wn1WEE02";");
props.put("group.id", "log-server-group");

方案对比总结

机制	JAAS 中定义	kafka-configs.sh 创建	安全性	推荐场景
SASL/PLAIN	在 `kafka_server_jaas.conf` 中	不需要	低（密码明文传输）	开发/测试
SASL/SCRAM-SHA-512	不需要	动态创建	高（密码不传输）	生产环境

总体而言，通过 kafka_server_jaas.conf 配合 PLAIN 机制可以快速完成 Kafka KRaft 的 SASL 认证配置。若需达到生产级安全标准，建议将 sasl.enabled.mechanisms 改为 SCRAM-SHA-512，并通过 kafka-configs.sh 创建用户。

Kafka KRaft模式启动的JAAS配置示例

附件一：Kafka 客户端四类常用的安全协议

PLAINTEXT  SSL  SASL_PLAINTEXT  SASL_SSL

安全协议类型	传输加密能力	身份认证能力	核心特点	典型适用场景	安全等级
PLAINTEXT	无任何加密，所有数据明文传输	无身份校验，连通网络即可访问	配置最简单、性能损耗几乎为0，完全无安全防护	完全隔离的内网开发测试环境，禁止在生产/公网使用	极低
SSL	基于TLS/SSL全程加密传输，防窃听、防篡改	仅做传输层加密，不提供账号类身份校验	只保障数据传输链路安全，不做访问者身份管控	仅需要加密传输数据，不需要额外用户权限管控的集群	中等
SASL_PLAINTEXT	数据和认证信息均明文传输	通过SASL框架校验用户名密码，拦截未授权访问	实现了基础的用户权限管控，但账号密码存在被窃听风险	封闭内网环境中快速实现基础访问控制，不对外暴露	中高
SASL_SSL	全程TLS加密，所有传输数据密文传输	同时支持SASL账号密码身份校验	兼顾身份认证和传输加密，彻底避免数据泄露、账号盗用风险	生产环境集群、公网暴露的集群，是生产级标准安全配置	最高

Kafka KRaft模式启动的JAAS配置示例

附件二：Kafka 的几种 sasl.mechanism 对比

Kafka 官方支持的主流 SASL 认证机制，核心差异集中在密码传输方式、存储形态、安全性和运维成本几个维度。下表对比了常见的几种方案：

SASL 机制	密码传输形态	服务端密码存储	依赖外部组件	安全等级	核心特点	典型适用场景
PLAIN	明文传输	明文存储在 JAAS 配置文件中	无，完全内置实现	低	配置最简单，开发调试零门槛，但账号密码全程明文暴露，极易被窃听	仅用于完全隔离的内网开发测试环境，禁止生产使用
SCRAM-SHA-256 / SCRAM-SHA-512	传输随机挑战值，密码本身不直接传输	加盐哈希值存储在 Kafka 内部 Topic 中，无明文密码留存	无，完全内置实现	高	兼顾安全性和易用性，支持动态增删改用户，无需重启集群，是 Kafka 生产环境的主流标准方案	绝大多数自建生产集群，不需要额外引入外部认证服务的场景
GSSAPI (Kerberos)	基于 Ticket 票据完成身份校验，全程不传递密码	密码存储在独立的 Kerberos KDC 服务端	必须部署 Kerberos 域控服务	极高	企业级强认证方案，支持全集群统一身份管控，安全性拉满，但运维复杂度极高	大型金融、政企等已有成熟 Kerberos 体系的企业级生产集群
OAUTHBEARER	基于 JWT 令牌完成认证，不传递原始密码	无本地密码存储，依赖外部授权服务校验令牌有效性	必须对接 OAuth2 授权服务	高	支持动态令牌、细粒度权限、单点登录，适配云原生生态	云托管 Kafka 集群、需要对接统一 OAuth 身份体系的云原生场景
LDAP	需额外扩展自定义实现，原生不直接支持	密码存储在外部 LDAP 服务端	必须对接 LDAP 目录服务	中高	复用企业已有的账号体系，无需在 Kafka 侧重复维护用户	已有统一 LDAP 账号管理的企业，实现账号打通的场景