ZooKeeper的ACL实现源码阅读
- 2019 年 10 月 3 日
- 筆記
如果对您有帮助,欢迎点赞支持, 如果有不对的地方,欢迎指出批评
什么是ACL(Access Control List)
zookeeper在分布式系统中承担中间件的作用,它管理的每一个节点上可能都存储这重要的信息,因为应用可以读取到任意节点,这就可能造成安全问题,ACL的作用就是帮助zookeeper实现权限控制, 比如对节点的增删改查
addAuth客户端源码追踪入口
通过前几篇博客的追踪我们知道了,客户端启动三条线程,如下
- 守护线程 sendThread 负责客户端和服务端的IO通信
- 守护线程 EventThread 负责处理服务端和客户端有关事务的事件
- 主线程 负责解析处理用户在控制台的输入
所以本篇博客的客户端入口选取的是客户端的主程序processZKCmd(MyCommandOptions co), 源码如下
protected boolean processZKCmd(MyCommandOptions co) throws KeeperException, IOException, InterruptedException { // todo 在这个方法中可以看到很多的命令行所支持的命令 Stat stat = new Stat(); // todo 获取命令行输入中 0 1 2 3 ... 位置的内容, 比如 0 位置是命令 1 2 3 位置可能就是不同的参数 String[] args = co.getArgArray(); String cmd = co.getCommand(); if (args.length < 1) { usage(); return false; } if (!commandMap.containsKey(cmd)) { usage(); return false; } boolean watch = args.length > 2; String path = null; List<ACL> acl = Ids.OPEN_ACL_UNSAFE; LOG.debug("Processing " + cmd); if (cmd.equals("quit")) { System.out.println("Quitting..."); zk.close(); System.exit(0); } . . . . } else if (cmd.equals("addauth") && args.length >= 2) { byte[] b = null; if (args.length >= 3) b = args[2].getBytes(); zk.addAuthInfo(args[1], b); } else if (!commandMap.containsKey(cmd)) { usage(); } return watch; }假如说我们是想在服务端的上下文中添加一个授权的信息, 假设我们这样写addauth digest lisi:123123,这条命令经过主线程处理之后就来到上述源码的else if (cmd.equals("addauth") && args.length >= 2)部分, 然后调用了ZooKeeper.java的zk.addAuthInfo(args[1], b); 源码如下:
public void addAuthInfo(String scheme, byte auth[]) { cnxn.addAuthInfo(scheme, auth); }继续跟进ClientCnxn的addAuthInfo()方法,源码如下 它主要做了两件事:
- 将sheme + auth 进行了封装
- 然后将seheme + auth 封装进了封装进Request,在经过
queuePacket()方法封装进packet,添加到outgoingQueue中等待sendThread将其消费发送服务端
public void addAuthInfo(String scheme, byte auth[]) { if (!state.isAlive()) { return; } // todo 将用户输入的权限封装进 AuthData // todo 这也是ClientCnxn的内部类 authInfo.add(new AuthData(scheme, auth)); // todo 封装进一个request中 queuePacket(new RequestHeader(-4, OpCode.auth), null, new AuthPacket(0, scheme, auth), null, null, null, null, null, null); }addAuth服务端的入口
在服务端去处理客户端请求的是三个Processor 分别是:
PrepRequestProcessor负责更新状态SyncRequestProcessor同步处理器,主要负责将事务持久化FinalRequestProcessor主要负责响应客户端
服务端选取的入口是 NIOServerCnxn.java的readRequest(), 源码如下:
// todo 解析客户端传递过来的packet private void readRequest() throws IOException { // todo ,跟进去看zkserver 如何处理packet zkServer.processPacket(this, incomingBuffer); }继续跟进processPacket(),源码如下:
虽然这段代码也挺长的,但是它的逻辑很清楚,
- 将客户端发送过来的数据反序列化进new出来的RequestHeader
- 跟进RequestHeader判断是否需要auth鉴定
- 需要:
- 创建AuthPacket对象,将数据反序列化进它里面
- 使用
AuthenticationProvider进行权限验证 - 如果成功了返回
KeeperException.Code.OK其他的状态是抛出异常中断操作
- 不需要
- 将客户端端发送过来的数据封装进Request
- 将Request扔向请求处理链进一步处理
- 需要:
其中AuthenticationProvider在这里设计的很好,他是个接口,针对不同的schme它有不同的实现子类,这样当前的ap.handleAuthentication(cnxn, authPacket.getAuth()); 一种写法,就可以实现多种不同的动作
// todo 在ZKserver中解析客户端发送过来的request public void processPacket(ServerCnxn cnxn, ByteBuffer incomingBuffer) throws IOException { // We have the request, now process and setup for next // todo 从bytebuffer中读取数据， 解析封装成 RequestHeader InputStream bais = new ByteBufferInputStream(incomingBuffer); BinaryInputArchive bia = BinaryInputArchive.getArchive(bais); RequestHeader h = new RequestHeader(); // todo 对RequestHeader 进行反序列化 h.deserialize(bia, "header"); // Through the magic of byte buffers, txn will not be pointing to the start of the txn // todo incomingBuffer = incomingBuffer.slice(); // todo 对应用户在命令行敲的 addauth命令 // todo 这次专程为了 探究auth而来 if (h.getType() == OpCode.auth) { LOG.info("got auth packet " + cnxn.getRemoteSocketAddress()); // todo 创建AuthPacket,将客户端发送过来的数据反序列化进 authPacket对象中 /** 下面的authPacket的属性 * private int type; * private String scheme; * private byte[] auth; */ AuthPacket authPacket = new AuthPacket(); ByteBufferInputStream.byteBuffer2Record(incomingBuffer, authPacket); String scheme = authPacket.getScheme(); AuthenticationProvider ap = ProviderRegistry.getProvider(scheme); Code authReturn = KeeperException.Code.AUTHFAILED; if(ap != null) { try { // todo 来到这里进一步处理, 跟进去 // todo AuthenticationProvider 有很多三个实现实现类, 分别处理不同的 Auth , 我们直接跟进去digest类中 authReturn = ap.handleAuthentication(cnxn, authPacket.getAuth()); } catch(RuntimeException e) { LOG.warn("Caught runtime exception from AuthenticationProvider: " + scheme + " due to " + e); authReturn = KeeperException.Code.AUTHFAILED; } } if (authReturn!= KeeperException.Code.OK) { if (ap == null) { LOG.warn("No authentication provider for scheme: " + scheme + " has " + ProviderRegistry.listProviders()); } else { LOG.warn("Authentication failed for scheme: " + scheme); } // send a response... ReplyHeader rh = new ReplyHeader(h.getXid(), 0, KeeperException.Code.AUTHFAILED.intValue()); cnxn.sendResponse(rh, null, null); // ... and close connection cnxn.sendBuffer(ServerCnxnFactory.closeConn); cnxn.disableRecv(); } else { if (LOG.isDebugEnabled()) { LOG.debug("Authentication succeeded for scheme: " + scheme); } LOG.info("auth success " + cnxn.getRemoteSocketAddress()); ReplyHeader rh = new ReplyHeader(h.getXid(), 0, KeeperException.Code.OK.intValue()); cnxn.sendResponse(rh, null, null); } return; } else { if (h.getType() == OpCode.sasl) { Record rsp = processSasl(incomingBuffer,cnxn); ReplyHeader rh = new ReplyHeader(h.getXid(), 0, KeeperException.Code.OK.intValue()); cnxn.sendResponse(rh,rsp, "response"); // not sure about 3rd arg..what is it? return; } else { // todo 将上面的信息包装成 request Request si = new Request(cnxn, cnxn.getSessionId(), h.getXid(), h.getType(), incomingBuffer, cnxn.getAuthInfo()); si.setOwner(ServerCnxn.me); // todo 提交request， 其实就是提交给服务端的 process处理器进行处理 submitRequest(si); } } cnxn.incrOutstandingRequests(h); }因为我们的重点是查看ACL的实现机制,所以继续跟进 ap.handleAuthentication(cnxn, authPacket.getAuth());(选择DigestAuthenticationProvier的实现) 源码如下:
这个方法算是核心方法, 主要了做了如下几件事
- 我们选择的是Digest模式,针对用户的输入
lisi:123123这部分信息生成数字签名 - 如果这个用户是超级用户的话,在ServerCnxn维护的authInfo中添加
super : ''比较是超级管理员 - 将当前的信息封装进Id对象,添加到 authInfo
- 认证成功?
- 返回
KeeperException.Code.OK;
- 返回
- 认证失败
- 返回
KeeperException.Code.AUTHFAILED;
- 返回
public KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte[] authData) { String id = new String(authData); try { // todo 生成一个签名, 跟进去看看下 签名的处理步骤, 就在上面 String digest = generateDigest(id); if (digest.equals(superDigest)) { // todo 从这个可以看出, zookeeper是存在超级管理员用户的, 跟进去看看 superDigest 其实就是读取配置文件得来的 //todo 满足这个条件就会在这个list中多存一个权限 cnxn.addAuthInfo(new Id("super", "")); } // todo 将scheme + digest 添加到cnxn的AuthInfo中 , cnxn.addAuthInfo(new Id(getScheme(), digest)); // todo 返回认证成功的标识 return KeeperException.Code.OK; } catch (NoSuchAlgorithmException e) { LOG.error("Missing algorithm", e); } return KeeperException.Code.AUTHFAILED; } authInfo有啥用?
它其实是一个List数组,存在于内存中,一旦客户端关闭了这个数组中存放的内容就全部丢失了
一般我们是这么玩的,比如,我们创建了一个node,但是不想让任何一个人都能访问他里面的数据,于是我们就他给添加一组ACL权限, 就像下面这样
# 创建节点 [zk: localhost:2181(CONNECTED) 0] create /node2 2 Created /node2 # 添加一个用户 [zk: localhost:2181(CONNECTED) 1] addauth digest lisi:123123 # 给这个node2节点设置一个;lisi的用户,只有这个lisi才拥有node的全部权限 [zk: localhost:2181(CONNECTED) 2] setAcl /node2 auth:lisi:cdrwa cZxid = 0x2d7 ctime = Fri Sep 27 08:19:58 CST 2019 mZxid = 0x2d7 mtime = Fri Sep 27 08:19:58 CST 2019 pZxid = 0x2d7 cversion = 0 dataVersion = 0 aclVersion = 1 ephemeralOwner = 0x0 dataLength = 1 numChildren = 0 [zk: localhost:2181(CONNECTED) 3] getAcl /node2 'digest,'lisi:dcaK2UREXUmcqg6z9noXkh1bFaM= : cdrwa这时候断开客户端的连接, 打开一个新的连接,重试get
# 会发现已经没有权限了 [zk: localhost:2181(CONNECTED) 1] getAcl /node2 Authentication is not valid : /node2 # 重新添加auth [zk: localhost:2181(CONNECTED) 2] addauth digest lisi:123123 [zk: localhost:2181(CONNECTED) 3] getAcl /node2 'digest,'lisi:dcaK2UREXUmcqg6z9noXkh1bFaM= : cdrwa可以看到,经过本轮操作后,node2节点有了已经被持久化的特征,lisi才能对他有全部权限,这么看addauth digest lisi:123123就有点添加了一个用户的概念,只不过这个信息最终会存放在上面提到的authInfo中, 这也是为啥一旦重启了,想要访问得重新添加权限的原因
言归正传,接着看上面的函数,我们看它是如何进行签名的, 拿lisi:123123举例子
- 使用:分隔
- 将后半部分的123123经过SHA1加密
- 再进行BASE64加密
- 最后拼接 lisi:sugsduyfgyuadgfuyadadfgba…
// todo 签名的处理步骤 static public String generateDigest(String idPassword) throws NoSuchAlgorithmException { //todo 根据: 分隔 String parts[] = idPassword.split(":", 2); //todo 先用SHA1进行加密 byte digest[] = MessageDigest.getInstance("SHA1").digest( idPassword.getBytes()); //todo 再用BASE64进行加密 // todo username:签名 return parts[0] + ":" + base64Encode(digest); }加密完成后有样的判断,证明zookeeper中是有超级管理员角色存在的
if (digest.equals(superDigest)) { // todo 从这个可以看出, zookeeper是存在超级管理员用户的, 跟进去看看 superDigest 其实就是读取配置文件得来的 //todo 满足这个条件就会在这个list中多存一个权限 cnxn.addAuthInfo(new Id("super", "")); }点击superDisgest,他是这样介绍的
/** specify a command line property with key of * "zookeeper.DigestAuthenticationProvider.superDigest" * and value of "super:<base64encoded(SHA1(password))>" to enable * super user access (i.e. acls disabled) */ // todo 在命令行中指定 key = zookeeper.DigestAuthenticationProvider.superDigest // todo 指定value = super:<base64encoded(SHA1(password))> // todo 就可以开启超级管理员用户 private final static String superDigest = System.getProperty( "zookeeper.DigestAuthenticationProvider.superDigest");小结:
到目前为止,我们就知道了addauth在底层源码做出了哪些动作,以及服务端将我们手动添加进来的权限信息都放在内存中
setACL源码追踪入口
同样会和addAuth操作一样,主线程从控制台解析出用户的请求封装进request然后封装进pakcet发送给服务端
setACL服务端的处理逻辑
请求来到服务端,在遇到第一次checkAcl之间,请求会顺利的来到第一个处理器PrepRequestProcessor, 所以我们的入口点就是这里
protected void pRequest(Request request) throws RequestProcessorException { // LOG.info("Prep>>> cxid = " + request.cxid + " type = " + // request.type + " id = 0x" + Long.toHexString(request.sessionId)); request.hdr = null; request.txn = null; // todo 下面的不同类型的信息， 对应这不同的处理器方式 try { switch (request.type) { case OpCode.create: // todo 创建每条记录对应的bean , 现在还是空的, 在面的pRequest2Txn 完成赋值 CreateRequest createRequest = new CreateRequest(); // todo 跟进这个方法， 再从这个方法出来，往下运行，可以看到调用了下一个处理器 pRequest2Txn(request.type, zks.getNextZxid(), request, createRequest, true); break; case OpCode.delete: DeleteRequest deleteRequest = new DeleteRequest(); pRequest2Txn(request.type, zks.getNextZxid(), request, deleteRequest, true); break; case OpCode.setData: SetDataRequest setDataRequest = new SetDataRequest(); pRequest2Txn(request.type, zks.getNextZxid(), request, setDataRequest, true); break; case OpCode.setACL: // todo 客户端发送的setAcl命令, 会流经这个选项 SetACLRequest setAclRequest = new SetACLRequest(); /** SetACLRequest的属性 * private String path; * private java.util.List<org.apache.zookeeper.data.ACL> acl; * private int version; */ // todo 继续跟进去 pRequest2Txn(request.type, zks.getNextZxid(), request, setAclRequest, true); break; case OpCode.check:用户在控制台输入类似 setAcl /node4 digest:zhangsan:jA/7JI9gsuLp0ZQn5J5dcnDQkHA= 请求将被解析运行到上面的case OpCode.setACL: 它new了一个空的对象SetACLRequest,这个对象一会在pRequest2Txn()函数中进行初始化
继续跟进pRequest2Txn(request.type, zks.getNextZxid(), request, setAclRequest, true);
源码如下: 它的解析我写在这段代码的下面
protected void pRequest2Txn(int type, long zxid, Request request, Record record, boolean deserialize) throws KeeperException, IOException, RequestProcessorException { // todo 使用request的相关属性,创建出 事务Header request.hdr = new TxnHeader(request.sessionId, request.cxid, zxid, Time.currentWallTime(), type); switch (type) { case OpCode.create: // todo 校验session的情况 zks.sessionTracker.checkSession(request.sessionId, request.getOwner()); CreateRequest createRequest = (CreateRequest)record; . . . case OpCode.setACL: // todo 检查session的合法性 zks.sessionTracker.checkSession(request.sessionId, request.getOwner()); // todo record; 上一步中new 出来的SetACLRequest空对象, // todo 这样设计的好处就是, 可以进行横向的扩展, 让当前这个方法 PRequest2Tm()中可以被Record的不同实现类复用 SetACLRequest setAclRequest = (SetACLRequest)record; // todo 将结果反序列化进 setAclRequest if(deserialize) ByteBufferInputStream.byteBuffer2Record(request.request, setAclRequest); // todo 获取path 并校验 path = setAclRequest.getPath(); validatePath(path, request.sessionId); // todo 去除重复的acl listACL = removeDuplicates(setAclRequest.getAcl()); if (!fixupACL(request.authInfo, listACL)) { // todo request.authInfo的默认值就是本地ip, 如果没有这个值的话,在server本地,client都连接不上 throw new KeeperException.InvalidACLException(path); } //todo 获取当前节点的record nodeRecord = getRecordForPath(path); // todo 共用的checkACL 方法 // todo 在setAcl时,使用checkACL进行权限的验证 // todo nodeRecord.acl 当前节点的acl // todo 跟进这个方法 checkACL(zks, nodeRecord.acl, ZooDefs.Perms.ADMIN, request.authInfo); version = setAclRequest.getVersion(); currentVersion = nodeRecord.stat.getAversion(); if (version != -1 && version != currentVersion) { throw new KeeperException.BadVersionException(path); } version = currentVersion + 1; request.txn = new SetACLTxn(path, listACL, version); nodeRecord = nodeRecord.duplicate(request.hdr.getZxid()); nodeRecord.stat.setAversion(version); addChangeRecord(nodeRecord); break; // todo createSession///////////////////////////////////////////////////////////////// case OpCode.createSession: . . .- 先说一下有个亮点, 就是这个函数中倒数第二个参数位置写着需要的参数是record类型的,但是实际上我们传递进来的类型是
SetACLRequest上面的这个空对象SetACLRequest这样的设计使得的扩展性变得超级强
这是record的类图
言归正传,来到这个函数算是进入了第二个高潮, 他主要做了这几件事
- 检查session是否合法
- 将数据反序列化进
SetACLRequest - 校验path是否合法
- 去除重复的acl
- CheckAcl鉴权
我们重点看最后两个地方
去除重复的acl
fixupACL(request.authInfo, listACL)
这个函数很有趣,举个例子,通过控制台,我们连接上一个服务端,然后通过如下命令往服务端的authInfo集合中添加三条数据
addauth digest lisi1:1 addauth digest lisi2:2 addauth digest lisi3:3然后给lisi授予针对node1的权限
setAcl /node auth:lisi1:123123:adr再次查看,会发现lisi2 lisi3同样有了对node1的权限
CheckAcl鉴权
checkACL(zks, nodeRecord.acl, ZooDefs.Perms.ADMIN,request.authInfo); 源码如下:
这个函数的主要逻辑就是,从头到尾的执行,只要满足了合法的权限就退出,否则运行到最后都没有合法的权限,就抛出没有授权的异常从而中断请求,如果正常返回了,说明权限经过了验证,既然经过了验证request就可以继续在process链上运行,进一步进行处理
static void checkACL(ZooKeeperServer zks, List<ACL> acl, int perm, List<Id> ids) throws KeeperException.NoAuthException { // todo 这是个写在配置文件中的 配置属性 zookeeper.skipACL , 可以关闭acl验证 if (skipACL) { return; } // todo 当前的节点没有任何验证的规则的话,直接通过 if (acl == null || acl.size() == 0) { return; } // todo 如果ids中存放着spuer 超级用户,也直接通过 for (Id authId : ids) { if (authId.getScheme().equals("super")) { return; } } // todo 循环当前节点上存在的acl点 for (ACL a : acl) { Id id = a.getId(); // todo 使用& 位运算 , 去ZooDefs类看看位移的情况 // todo 如果设置的权限为 a.getPerms() =dra = d+r+a = 8+1+16 = 25 // todo perm = 16 /** * 进行&操作 * 25 & 16 * 11001 * 10000 * 结果 * 10000 * 结果不是0 ,进入if { } */ if ((a.getPerms() & perm) != 0) { if (id.getScheme().equals("world") && id.getId().equals("anyone")) { return; } AuthenticationProvider ap = ProviderRegistry.getProvider(id.getScheme()); if (ap != null) { for (Id authId : ids) { if (authId.getScheme().equals(id.getScheme()) && ap.matches(authId.getId(), id.getId())) { return; } } } } } //todo 到最后也没返回回去, 就抛出异常 throw new KeeperException.NoAuthException(); }几个重要的参数
- acl
- 当前node已经存在的 需要的权限信息
scheme:id;
- 当前node已经存在的 需要的权限信息
- perm
- 当前用户的操作需要的权限
- ids
- 我们在上面通过addauth添加进authInfo列表中的信息
- skip跳过权限验证
static boolean skipACL; static { skipACL = System.getProperty("zookeeper.skipACL", "no").equals("yes"); if (skipACL) { LOG.info("zookeeper.skipACL=="yes", ACL checks will be skipped"); } }这里面在验证权限时存在位运算,prem在ZooDFS.java中维护
// todo 位移的操作 @InterfaceAudience.Public public interface Perms { // 左移 int READ = 1 << 0; //1 2的0次方 int WRITE = 1 << 1; //2 2的1次方 int CREATE = 1 << 2; // 4 int DELETE = 1 << 3; // 8 int ADMIN = 1 << 4; // 16 int ALL = READ | WRITE | CREATE | DELETE | ADMIN; //31 /** * 00001 * 00010 * 00100 * 01000 * 10000 * * 结果11111 = 31 * */ }总结:
通过跟踪上面的源码,我们知道了zookeeper的权限acl是如何实现的,以及客户端和服务端之间是如何相互配合的
- 客户端同样是经过主线程跟进不同的命令类型,将请求打包packet发送到服务端
- 服务端将addauth添加认证信息保存在内存中
- node会被持久化,因为它需要的认证同样被持久化
- 在进行处理request之前,会进行checkAcl的操作,它是在第一个处理器中完成的,只有经过权限认证,request才能继续在processor链中往下传递
如果对您有帮助,欢迎点赞支持, 如果有不对的地方,欢迎指出批评
