由上一篇博文，讲解了SASL认证的安装过程。本文主要围绕ACL设置进行说明。 参考： kafka authentorization：官方 一、开启ZK ACL（可选，内网环境，用户无机器访问权限时） 给kafka meta都加上zk的acl，默认是world，即任何人可访问。 zk acl详见：https://www.cnblogs.com/dalianpai/p/12748144.html 执行已有kafka meta的迁移 vim kafka/bin/zookeeper-security-migration.sh 执行迁移 到zk上查看生效 二、设置kafka acl 上篇文章已经在server.properties中添加了acl的配置。这里执行命令设置acl。 kafka的acl对象，即资源类型分为 cluster, topic, consumer group, transation id, token。实际应用中，主要以topic及consumer group为主进行运维管控。即控制”哪个用户的哪个消费组可以访问哪个topic“。 常用acl操作 列出 test 这个 topic 的 ACL 列表 对用户 test 授权，以访问test 这个 topic。 先添加scram用户 test 因为添加了zk的acl，所以需指定ZK的acl jaas账号信息。若不指定ZK的jaas账号信息，会报如下错误： 加acl认证信息的方式：先调整bin/kafka-run-class.sh，用于zk acl验证。这个文件被大多数的kafka bin目录下的script所引用，如添加topic的脚本等，所以改它最方便，添加一行。 再执行一次添加即可，输出如下提示表示添加用户test完成。 添加consumer 授权方式1，先加topic权限： 输出： 再添加消费组权限： 添加consumer 授权方法2，参考文档。一步到位： […]
kafka监控工具众多，使用过 yahoo的Kafka Manager, 滴滴的kafka manager, kafka eagle, 也造过kafka offset monitor, 甚至有结合kibana与prometheus做的kafka消费监控面板。最近又接触了这个go写的界面清爽的kowl，详见github。 官方支持docker，参考Dockerfile整理一下本地开发环境搭建过程: 1. 后端构建 安装依赖 go mod download 构建 cd backend && go build -o ./bin/kowl ./cmd/api，生成名为kowl二进制可执行文件 2. 前端 安装依赖 npm install 构建 注释package.json中的build script中的ssl option，npm run build 3. 运行 目录结构 其中，kowl.yaml为doc中的config拷贝，调整相关配置 启动 ./kowl -config.filepath ./kowl.yaml {"level":"info","ts":"2022-02-16T16:08:24.297+0800","msg":"started Kowl","version":"","git_sha":"dev","built":""}{"level":"info","ts":"2022-02-16T16:08:24.299+0800","msg":"connecting to Kafka seed brokers, trying to fetch […]
kafka安全涉及3部份：传输加密，用户认证与授权，ZK开启ACL（Zookeeper存储了kafka的元数据以及用户信息，默认不开启acl所有用户可改，内网环境机器不对外开放可考虑使用默认不开启ZK ACL）。 词汇说明： 认证，即用户登陆。 授权，即管理用户可见的资源。 ACL，Access Control List 访问控制列表 SASL认证与Kerberos认证：SASL资料很多, java的见这里，Kerberos的资料，点这里。 Kafka权限控制指引 支持的认证方式 Kafka支持的认证类别有kerberos（和hadoop一样，大多数公司应该没用kerberos）、ldap（在传统企业中比较普遍）与rbac（这两个是要企业license，基于Confluence的平台组件MDS，自建集群如果没用kafka connect之类的组件，没用conflunece的cli，也用不了）、sasl/plain（用户信息用文件进行管理，修改需重启Kafka，生产大概率不会接受并使用）和sasl/scram（用户信息用api或命令行进行管理，存储在zk上，不需重启）。考虑用哪一种取决于公司自身的情况，这里主要是用sasl/scram。 接入现有认证系统 如果对zk不放心或想对接已有的认证系统，接入kafka权限管控，可参考这个kip-86自定义认证方式，文中有场景列表及sample code。 开启认证主要的关注点 使用者的需求，生产者和消费者都有哪些，场景如何，需求怎样，支持以后需要先验证，对使用方提供技术上的指引文档等。 开启方式，是重启集群还是迁移集群。开启认证不是平滑的，需要短暂中断业务流程。 使用的认证方式：基于现有的环境及实际需要。 运维成本：考虑运维、监控的方式及成本（监控需要admin账号） kafka版本是否需要升级：公司现有的版本是0.10.1，1.1，2.4等，需要升级吗？看使用哪种认证方式,rbac需要2.4+，sasl/scram只要0.9+，本文描述的基于2.4.1版本。 本文主要描述用户认证： 参考： sasl/scram 官方文档 sasl/plain 方式 一、zookeeper sasl开启（可选，内网环境，用户无机器访问权限时） vim zookeeper/conf/zoo.cfg vim zookeeper/conf/zookeeper_jaas.conf Server是ZK SERVER之间， Client是zkclient与zk server之间 vim zookeeper/bin/zkEnv.sh zk启动引入jaas配置 vim zookeeper/conf/adminclient_jaas.conf vim zookeeper/bin/zkCli.sh zkCli命令默认添加jaas 重启zk bin/zkServer.sh restart 验证 bin/zkCli.sh 是否成功，调整密码验证 二、配置kafka […]
