solr入门之solr安全控制的研究和实践(三) zookeeper访问控制
ZooKeeper Access Control(zookeeper 访问控制)--530-535
这部分描述的是使用zookeeper的访问控制列表(ACLs)对于solr.有关zookeeper ACLs的信息 ,可以看zookeeper的文档:
http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.htm
l#sc_ZooKeeperAccessControl.
●关于zookeeper的访问控制列表
●如何启用访问控制列表
●改变 访问控制列表的配置
●一个例子
About ZooKeeper ACLs
SolrCloud使用zookeeper对信息共享和协调。
本节描述如何配置Solr添加更多的限制性ACLs 对于zookeeper的内容创建,,
以及如何告诉Solr所需的凭证去访问zookeeper中的内容。
如果你想使用ACLs在zookeeper的
节点,您将必须激活这个功能;
默认情况下,
Solr 是不使用安全凭证去进行访问的.
改变Solr 有关内容在zookeeper中可能损害一个SolrCloud集群。例如
●
改变成集群状态信息错误或不一致可能导致SolrCloud集群行为异常
●
添加一个删除集合的任务,进行的监督将导致数据被删除从集群中。
你可能想启用zookeeper ACLs对于
Solr如果你授权访问zookeeper实体集合的你不相信,或者如果你想减少风险造成的不良行为,例如:
●
其他系统使用相同的zookeeper集合(“坏事”可能是由事故)。
你甚至可能想限制读取访问权限,如果你觉得有东西在zookeeper中,不是每个人都应该知道有关。或者你可能只是一般need-to-know-basis工作。
保护zookeeper本身可能意味着许多不同的事情。这部分是关于保护Solr的内容在
zookeeper中。zookeeper内容基本上保存在磁盘上,和在内存中(部分)在zookeeper运行时。本节并不是保护动zookeeper——数据在存储或管理员处理水平这是动物园管理员处理。
但这内容也可以通过
外部 zookeeper API 进行操作。外部程序可以连接到zookeeper进行 创建/更新/删除/阅读内容;例如,一个Solr节点在SolrCloud集群想 创建/更新/删除/读取,SolrJ客户想从集群进行读取。ACLS有责任去控制外部程序进行增删改查的操作。ACLs纪录了谁允许读, 更新、删除、创建等。
每一块信息(znode /内容)在zookeeper都有自己的一组acl,和继承或分享是不可能的。Solr默认行为是添加一个ACL在所有它创建的内容—一个ACL给任何人做任何的许可(这叫做 zookeeper的“open-unsafe ACL”)。
How to Enable ACLs
我们希望能够:
●控制Solr使用凭证去连接zookeeper.使用的凭证的获取在zookeeper平台的权限。
●
控制它“从外面”,所以,你不需要修改或重新编译Solr代码来打开它。
Solr节点,客户和工具(例如ZkCLI)总是使用一个java类称为SolrZkClient来处理他们 zookeeper的东西。这里所描述的解决方案的实现都是关于改变SolrZkClient。如果你在您的应用程序,使用SolrZkClient下面的描述也将适用于您的应用程序。
Controlling Credentials
控制哪些凭证提供者将使用配置zkCredentialsProvider属性solr.xml的< solrcloud >部分类的名称(在类路径)实现以下接口:
package org.apache.solr.common.cloud;
public interface ZkCredentialsProvider {
public class ZkCredentials {
String scheme;
byte[] auth;
public ZkCredentials(String scheme, byte[] auth) {
super();
this.scheme = scheme;
this.auth = auth;
}
String getScheme() {
return scheme;
}
byte[] getAuth() {
return auth;
}
}
Collection<ZkCredentials> getCredentials();
}
Solr决定使用哪些凭据的getCredentials()方法通过调用给定的凭证提供者。
如果没有提供程序配置,默认实现,DefaultZkCredentialsProvider被使用。
Out of the Box Implementations
你可以使用你自己的实现,但Solr有两种已经实现的实现:
●org.apache.solr.common.cloud.DefaultZkCredentialsProvider:
他的getCredentials()返回一个列表的长度为零,或者没有凭证使用。这是默认的,如果你不使用配置提供者在solr.xml
●
org.apache.solr.common.cloud.VMParamsSingleSetCredentialsDigestZkCredentialsPr
ovider:
这允许您使用系统属性定义您的凭据
它支持最多一组凭证。
"zkDigestUsername”和
“zkDigestPassword这组凭证将被添加getCredentials()返回的列表的凭证,如果两个用户名和密码被提供。
●
如果上面的一组凭证没有添加到列表中,该实现将退回到默认行为和返回(空的)从DefaultZkCredentialsProvider获取凭证列表
Controlling ACLs
You control which ACLs will be added by configuring zkACLProvider property in solr.xml 's <solrcloud>
section to the name of a class (on the classpath) implementing the following interface:
你控制ACLs将要添加到配置zkACLProvider属性在solr.xml的<solrcloud>部分,名字是
实现下列接口的类(在classpath)
package org.apache.solr.common.cloud;
public interface ZkACLProvider {
List<ACL> getACLsToAdd(String zNodePath);
}
当solr想创建一个新的znode,它决定了ACLs将通过调用getACLsT
oAdd()方法给定acl的提供者。如果没有配置提供者,默认实现
DefaultZkACLProvider被使用。
Out of the Box Implementations
你可以让你自己的实现,但Solr也提供了实现:
它返回一个列表的长度
z
NodePath-s.
单个ACL入口在条目列表中是"open-unsafe”。
这是默认的,如果你不使用solr.xml配置一个提供者。
●
org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLProvider:
这让你能定义acl使用系统属性
他的getACLsToAdd() 的实现没有使用任何zNodePath,所以全部的znodes将获得相同的
ACLs你设置的. 他支持添加一个或者多个下列选项:
●允许用户做所有的事情
●这个权限是ALL(允许全部的
CREATE, READ, WRITE, DELETE, and ADMI
N操作),
schema 是"digest"
●用户名和密码分别被系统属性"zkDigestUsername"和"zkDigestPassword"来定义
●ACL将不能添加到ACLs的列表除非提供用户名和密码
●仅仅允许用户进行读取操作
●
许可模式是“读”和schema 是“digest"
●用户名和密码分别被系统属性"zkDigestUsername"和"zkDigestPassword"来定义
●ACL将不能添加到ACLs的列表除非提供用户名和密码
如果上面的ACL没有一个被添加到ACLs列表中,DefaultZkACLProvider的(空的)ACL列在默认情况下使用。
注意到重叠与凭证提供者VMParamsSingleSetCredentialsDig系统属性的名称 estZkCredentialsProvider(如上所述)。这是让两个供应商合作好 也许常用方法:我们总是保护访问内容通过限制两个用户admin用户切换和 readonly-user——我们总是与凭证对应于同样的admin用户切换,基本如此 我们可以做任何事情的内容/ znodes我们自己创造。
你能获取到一个只读的凭证通过客户端连接你得solrcloud集群,例如:使用solrj客户端
他将能够读取任何需要的通过运行的solrJ连接.但是他不能修改zookeeper中的内容
Changing ACL Schemes
在Solr集群的生命周期内操作,你可以决定从一个无担保zookeeper移动获得有担保实例。
改变zkACLProvider的配置在solr.xml将确保新创建的节点是安全的,但不会保护现有数据。修改所有现有的ACLs,你可以使用:ZkCLI - cmd updateacls / zk-path。
改变ACLs在ZK中应该仅仅在你的solrcloud集群是停止时.如果你尝试在solr运行期间这么做,那么可能会导致集群的状态不一致或者某些节点无法被访问.要配置新的ACLs,可以运行
ZKCli 下列VM属性
-DzkACLProvider=...
-DzkCredentialsProvider=....
●
凭据提供程序必须是一个当前节点上的管理员权限。当省略,程序将不使用凭证(适合一个未加密的配置)。
●
ACL提供者将被用于计算新的ACLs。当省略,程序将设置所有的权限到每个用户,删除所有的安全保证.
你也许使用了VMParamsSingleSetCredentialsDigestZkCredentialsProvider和VMParamsAllAndReadonlyDigestZkACLProvider的实现类来定义之前页面中提到的属性.
改变ZK ACLs后,你要确保在你的solr.xml中的启动描述和他想匹配.
Example Usages
比如说你想保护全部的solr间在zookeeper中的内容. 你想要一个"admin"用户,能够去操作zookeeper上的所有内容--这个用户将被用于初始化solr在zookeeper中的内容和服务端solr的节点 。你也想要一个“readonly”用户只能从zookeeper读取内容——这个用户将被交给客户端使用,
下面是个例子:
●"admin"用户的username/password 是 admin-user/admin-password
●"readonly" 用户的username/password 是 readonly-user/readonly-password
提供的类名必须首先在solr.xml中配置:
...
<solrcloud>
...
<str
name="zkCredientialsProvider">
org.apache.solr.common.cloud.VMParamsSingleSetCredenti
alsDigestZkCredentialsProvider</str>
<str
name="zkACLProvider">
org.apache.solr.common.cloud.VMParamsAllAndReadonlyDigestZkACLP
rovider
</str>
To use ZkCLI:
SOLR_ZK_CREDS_AND_ACLS="-DzkDigestUsername=admin-user
-DzkDigestPassword=admin-password \
-DzkDigestReadonlyUsername=readonly-user
-DzkDigestReadonlyPassword=readonly-password"
java ... $SOLR_ZK_CREDS_AND_ACLS ... org.apache.solr.cloud.ZkCLI -cmd ...
对于使用 bin/solr, 在 bin/solr.in.sh 底部添加:
SOLR_ZK_CREDS_AND_ACLS="-DzkDigestUsername=admin-user
-DzkDigestPassword=admin-password \
-DzkDigestReadonlyUsername=readonly-user
-DzkDigestReadonlyPassword=readonly-password"
SOLR_OPTS="$SOLR_OPTS $SOLR_ZK_CREDS_AND_ACLS"
对于使用 bin\solr.cmd, 在 bin\solr.in.cmd 底部添加:
set SOLR_ZK_CREDS_AND_ACLS=-DzkDigestUsername=admin-user
-DzkDigestPassword=admin-password ^
-DzkDigestReadonlyUsername=readonly-user
-DzkDigestReadonlyPassword=readonly-password
set SOLR_OPTS=%SOLR_OPTS% %SOLR_ZK_CREDS_AND_ACLS%
使用SolrJ来进行连接:
SOLR_ZK_CREDS_AND_ACLS="-DzkDigestUsername=readonly-user
-DzkDigestPassword=readonly-password"
java ... $SOLR_ZK_CREDS_AND_ACLS ...
或者你自己写了代码去实现 SolrZKClient-s,你也许想去在代码级别去替代复写提供的接口的实现.