zookeeper 权限概述
老样子,先上连接,第一个是淘宝综合业务平台的(前几个月还叫通用产品团队呢我记得)http://rdc.taobao.com/team/jm/archives/947,其实基本上需要的他这里都有了,只是……太专业了,什么都说了唯独没说要怎么用。另一个是http://ec2-23-21-252-232.compute-1.amazonaws.com/wordpress/?p=14,写的
老样子,先上连接,第一个是淘宝综合业务平台的(前几个月还叫通用产品团队呢我记得)
http://rdc.taobao.com/team/jm/archives/947,其实基本上需要的他这里都有了,只是……太专业了,什么都说了唯独没说要怎么用。另一个是http://ec2-23-21-252-232.compute-
1.amazonaws.com/wordpress/?p=14,写的基本上也到位了,就是格式太差,看了半天看不到重点,所以今天再写一篇不完全自主知识产权的文章,稍微总结一下zookeeper中的权限管理。
其实综合业务(每次都想打“通用产品”)的文章写的已经很具体了不过可以稍微总结一下:
先来看下ACL的数据结构:
每一个znode节点上都可以设置一个访问控制列表,数据结构为List
ACL
+--perms int (allow What)
+--id Id
+--scheme String (Who)
+--id String (How)
一个ACL对象就是一个Id和permission对,用来表示哪个/哪些范围的Id(Who)在通过了怎样的鉴权(How)
之后,就允许进行那些操作(What):Who How What;permission(What)就是一个int表示的位码,每一
位代表一个对应操作的允许状态。类似unix的文件权限,不同的是共有5种操作:CREATE、READ、WRITE、
DELETE、ADMIN(对应更改ACL的权限);Id由scheme(Who)和一个具体的字符串鉴权表达式id(How)构成,用
来描述哪个/哪些范围的Id应该怎样被鉴权。Scheme事实上是所使用的鉴权插件的标识。id的具体格式和语
义由scheme对应的鉴权实现决定。
1、在zookeeperC的API里面,设置ACL的时候需要传入一个类型为structACL的结构指针,structACL结构类
型的定义如下:
structACL_vector {
int32_t count;
struct ACL *data;
};
可以看出,该结构包含两个字段:一个用于记录结构中ACL结构个数的,另一个应该是一个指向ACL结构数组
的指针(数组长度就由count决定了),ACL结构的定义如下:
struct ACL {
int32_tperms;
struct Idid;
};
这个结构也是两个字段:perms的意思就是permission,记录着权限,权限值从0到31说白了就是五个bit位
分别记录五种权限,从高位到低位分别是admin、delete、create、write、read,简称adcwr,权限的具体
含义不解释。另一个字段又是一个结构Id,(要处理这么样一个结构果断提防内存泄露)该结构的定义如下
:
struct Id {
char *scheme;
char * id;
};
到这里算是清楚了,里面两个字段:scheme标志着权限管理策略,目前有四个:world、auth、digest和ip
,具体不解释。Id字段是真正用来做权限匹配的,匹配成功就算你拥有权限。
整个结构综合业务那边解释的很清楚了,就不在说了,只是把具体定义给大家看看,说白了,如果要设置权
限,就要弄这么样一个结构出来,把需要的字段都填好,还要填对(比如如果scheme是“digest”的话,id
必须具有“user:password”的格式)。
2、可以设置节点权限的API主要有两个,一个是create,一个是setACL,前者是在创建的时候就设置了,后
者是另行设置,直观上来讲,后者设置能不能成功那都是不一定的,因为起码你要有a权限的。其实,前者
也不好说了,经典反例请看综合业务博客,不解释。
3、每个节点在创建的时候肯定要设置一个权限的,最经常设置的就是ZOO_OPEN_ACL_UNSAFE,也就是说
adcwr= 31、scheme = “world”、 id = “anyone”。简单地说:随便哪个家伙,想干什么都行。根据综
合业务博客,在一个zookeeper session创建以后会为该session创建默认的Id,其中scheme= “ip”、 id
就是客户端的IP地址,在访问节点的时候,zookeeper内部会将这个权限信息附加在消息中发送,消息在处
理的时候会将消息中的Id信息与节点的ACL信息进行匹配,对于ZOO_OPEN_ACL_UNSAFE权限的节点,任何匹配
都会是成功的。
4、除了在session创建时默认构造的Id,客户还可以指定自己的权限,这需要用到zoo_add_auth函数,该函
数就是用来重新声明自己的Id。比如,如果客户端要访问一个节点时发现权限不够,如果它知道节点的权限
设置,它就可以重新设置自己的Id,并达到访问节点的目的。
5、当scheme为“digest”的时候,id字段必须具有“user:password”的格式,当我们调用zoo_add_auth
函数时,password代表的字符串会经过SHA1加密。而调用getACL函数时我们看到的password字段代表的字符
串已经是加密后的字符串了。因此“digest”策略下,在调用setACL时,password部分的字符串必须是密文
,而调用zoo_add_auth函数password部分的字符串必须是明文。
用最简单的话总结,创建节点的时候会分配权限和验证Id,用户可以通过zoo_add_auth函数设置自己的验证
Id,同时用户可以通过setACL重设权限和验证Id,如果验证成功用户将拥有该节点赋予该验证Id的权限。
更多推荐
所有评论(0)