源起:工程现阶段中间件采用的是kafka.满足了大数据的高吞吐,项目间的解耦合,也增强了工程的容错率与扩展性.但是在安全这一块还有漏洞,kafka集群中,只要网站内的任何人知道kafka集群的ip与topic,都可以肆无忌惮的往集群中的topic中发送数据与消费数据. 经过调研:kafka的sasl acl可以设置安全机制,给每个主题设置多个用户,不同的用户赋予不同的读写权限. A B 俩个用户,A用户允许读写kafka中的topic1,B用户不允许读写kafka中的topic1,这就成功控制了

一.简介 在Kafka0.9版本之前,Kafka集群时没有安全机制的.Kafka Client应用可以通过连接Zookeeper地址,例如zk1:2181:zk2:2181,zk3:2181等.来获取存储在Zookeeper中的Kafka元数据信息.拿到Kafka Broker地址后,连接到Kafka集群,就可以操作集群上的所有主题了.由于没有权限控制,集群核心的业务主题时存在风险的. 本文主要使用SASL+ACL 二.技术关键点 配置文件 修改broker启动所需的server.propert

kafka系列文章 第一章 linux单机安装kafka 第二章 kafka--集群安裝部署(自带zookeeper) 第三章 Kafka SASL/SCRAM+ACL实现动态创建用户及权限控制 Kafka SASL/SCRAM+ACL实现动态创建用户及权限控制** 使用SASL / SCRAM进行身份验证 请先在不配置任何身份验证的情况下启动Kafka 1. 创建SCRAM Credentials Kafka中的SCRAM实现使用Zookeeper作为凭证(credential)存储. 可以使

分布式协调服务Zookeeper集群之ACL篇 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.zookeeper ACL相关知识概览 1>.zookeeper官方文档(http://zookeeper.apache.org/doc/r3.4.14/zookeeperProgrammers.html#sc_ZooKeeperAccessControl) 2>.使用ACL的ZooKeeper访问控制的特别说明 ZooKeeper使用ACL来控制对其znode(ZooKeep

1.概述 在Kafka0.9版本之前,Kafka集群时没有安全机制的.Kafka Client应用可以通过连接Zookeeper地址,例如zk1:2181:zk2:2181,zk3:2181等.来获取存储在Zookeeper中的Kafka元数据信息.拿到Kafka Broker地址后,连接到Kafka集群,就可以操作集群上的所有主题了.由于没有权限控制,集群核心的业务主题时存在风险的. 2.内容 2.2 身份认证 Kafka的认证范围包含如下: Client与Broker之间 Broker与Br

<Apache kafka实战>读书笔记-管理Kafka集群安全之ACL篇 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 想必大家能看到这篇博客的小伙伴,估计你对kafka已经有了深入对一步了解了,因为现在的你已经不考虑如何部署kafka以及调优了,而是考虑到kafka安全的问题.其实,在很多企业中,很少有人考虑到kafka的安全,小到几十人的小型互联网公司,达到某些云平台的云服务(我这里就不说是哪家云公司了),他们默认都是不会给kafka配置相关安全策略的,而是要求用户自

自0.9.0.0.版本引入Security之后,Kafka一直在完善security的功能.当前Kafka security主要包含3大功能:认证(authentication).信道加密(encryption)和授权(authorization).信道加密就是为client到broker.broker到broker以及工具脚本与broker之间的数据传输配置SSL:认证机制主要是指配置SASL,而授权是通过ACL接口命令来完成的. 生产环境中,用户若要使用SASL则必须配置Kerberos,但

一.概述 在Kafka0.9版本之前,Kafka集群时没有安全机制的.Kafka Client应用可以通过连接Zookeeper地址,例如zk1:2181:zk2:2181,zk3:2181等.来获取存储在Zookeeper中的Kafka元数据信息.拿到Kafka Broker地址后,连接到Kafka集群,就可以操作集群上的所有主题了.由于没有权限控制,集群核心的业务主题时存在风险的. 权限控制类型 kafka权限控制整体可以分为三种类型: 基于SSL 基于Kerberos(此认证一般基于CDH

一.场景 线上已经有kafka集群,服务运行稳定.但是因为产品升级,需要对kakfa做安全测试,也就是权限验证. 但是增加权限验证,会不会对性能有影响呢?影响大吗?不知道呀! 因此,本文就此来做一下对比! 测试环境 本文使用的是单机kafka测试,仅在一台服务器做测试. 使用的kafka版本为kafka_2.12-2.1.0,zk直接使用kafka自带的. 硬件配置为:1(核)-4G内容-40G硬盘 二.普通版安装 关于普通版的kafka,请参考链接: https://www.cnblogs.c

一.简介 自0.9.0.0.版本引入Security之后,Kafka一直在完善security的功能.当前Kafka security主要包含3大功能:认证(authentication).信道加密(encryption)和授权(authorization).信道加密就是为client到broker.broker到broker以及工具脚本与broker之间的数据传输配置SSL:认证机制主要是指配置SASL,而授权是通过ACL接口命令来完成的. 生产环境中,用户若要使用SASL则必须配置Kerbe

Zookeeper--Watcher 和 ACL Watcher (观察) Zookeeper中的znode可以被监控,这是zk的核心特性. 通过exists,getChildren和getData这些读操作可以设置观察,通过create,delete和setData这些写操作触发观察.当一个观察被触发时会产生一个事件,这个观察和触发它的操作共同决定了观察事件的类型. 1.当所观察的znode被创建,删除或其数据被更新时,设置在exists操作上的观察被触发. 2.当所观察的znode被删除或其

概述 传统的文件系统中,ACL分为两个维度,一个是属组,一个是权限,子目录/文件默认继承父目录的ACL.而在Zookeeper中,node的ACL是没有继承关系的,是独立控制的. Zookeeper的ACL,可以从三个维度来理解:一是scheme; 二是user; 三是permission,通常表示为scheme:id:permissions, 下面从这三个方面分别来介绍: 1.scheme: scheme 对应于采用哪种方案来进行权限管理,zookeeper实现了一个pluggable的ACL

操作 create:创建一个znode(必须要有父节点)delete:删除一个znode(该znode不能有任何子节点)exists:测试一个znode是否存在并且查询它的元数据getACL,setACL:获取/设置一个znode的ACLgetChildren:获取一个znode的子节点列表getData,setData:获取/设置一个znode所保存的数据sync:将客户端的znode视图与ZooKeeper同步 ZooKeeper中的更新操作是有条件的.在使用delete或setData操作

转载请注明原创地址:http://www.cnblogs.com/dongxiao-yang/p/7131626.html kafka从0.9版本以后引入了集群安全机制,由于最近需要新搭建一套kafka集群,决定采用SASL/GSSAPI (Kerberos) 作为新集群的权限系统基础,本次新集群版本为0.10.2.0. 团队内部已有同学搭建了专门的kerberos服务器,所以省掉了自建kerberos的步骤. (1)首先是为broker每台服务器在kerber服务器生成相应的principal

一.背景 kafka提供了多种安全认证机制,主要分为SSL和SASL2大类.其中SASL/PLAIN是基于账号密码的认证方式,比较常用.最近做了个kafka的鉴权,发现官网上讲的不是很清楚,网上各种博客倒是很多,但是良莠不齐,巨多坑.经过一天的研究,终于搞定了,特在此记录下. 二.环境 操作系统:linux kafka版本:kafka_2.12-0.11.0.1 zookeeper版本:zookeeper-3.5.1-alpha 三.认证步骤 3.1.Zookeeper配置和启动 1.为zook

什么是ACL(Access Control List) zookeeper在分布式系统中承担中间件的作用,它管理的每一个节点上可能都存储这重要的信息,因为应用可以读取到任意节点,这就可能造成安全问题,ACL的作用就是帮助zookeeper实现权限控制, 比如对节点的增删改查 点击查上篇博客中客户端使用acl的详解 addAuth客户端源码追踪入口 通过前几篇博客的追踪我们知道了,客户端启动三条线程,如下 守护线程 sendThread 负责客户端和服务端的IO通信 守护线程 EventThrea

一.背景 在我们部署完kafka之后,虽然我们已经可以“肆意”的用kafka了,但是在一个大公司的实际生产环境中,kafka集群往往十分庞大,每个使用者都应该只关心自己所负责的Topic,并且对其他人所使用的Topic没有权限.这样一来可以将资源隔离开来,二来可以防止误操作. 在权限控制之前,我们必须要启用的就是用户认证,没有用户,自然没有权限一说了. 二.kafka启用kerberos认证 2.1 在KDC中添加kafka用户,并生成keytab 新建kfaka用户 kadmin.local

ZooKeeper的ACL机制 zookeeper通过ACL机制控制znode节点的访问权限. 首先介绍下znode的5种操作权限:CREATE.READ.WRITE.DELETE.ADMIN 也就是 增.删.改.查.管理权限,这5种权限简写为crwda(即:每个单词的首字符缩写)注:这5种权限中,delete是指对子节点的删除权限,其它4种权限指对自身节点的操作权限 身份的认证有4种方式: world:默认方式,相当于全世界都能访问 auth:代表已经认证通过的用户(cli中可以通过addau

kafka SASL认证配置 1.找到kafka安装根目录,在config文件夹下创建kafka_server_jaas.conf,写入 KafkaServer { org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="admin-secret" user_admin="admin-secret" user_alice

1.SASL认证机制版本支持 SASL/GSSAPI (Kerberos) - starting at version 0.9.0.0SASL/PLAIN - starting at version 0.10.0.0SASL/SCRAM-SHA-256 and SASL/SCRAM-SHA-512 - starting at version 0.10.2.0 2.以下采用SASL/PLAIN进行认证操作 zookeeper配置 1)修改zoo.cfg增加两行配置: authProvider.1=