本研究基于solr官方文档:
链接：http://pan.baidu.com/s/1geAadZ9 密码：02x0
solr从5.3.0开始提供了安全验证的机制,具体有以下几种方式:
Kerberos Authentication Plugin
Basic Authentication Plugin
Rule-Based Authorization Plugin
Custom authentication or authorization plugin
具体使用要求如下:
Basic authentication: SolrCloud only.
Kerberos authentication: SolrCloud or standalone mode.
Rule-based authorization: SolrCloud only.
要是使用集群模式,需要上传一个文件到zookeeper中,即
security.json格式如下
{
"authentication" : {
"class": "class.that.implements.authentication"
},
"authorization": {
"class": "class.that.implements.authorization"
}
}
上传脚本:
server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd put
/security.json
今天先到这里,mark一下到501页.
Solr has two implementations of authentication plugins:
Kerberos Authentication Plugin
Basic Authentication Plugin
这两个插件的安全验证部分是已经实现了的.直接在security.json中配置就可以了
授权部分需要自己去实现AuthorizationPlugin
Authorization
An authorization plugin can be written for Solr by extending the AuthorizationPlugin interface.
加载自定义插件
Loading a Custom Plugin
Make sure that the plug-in implementation is in the classpath.
The plugin can then be initialized by specifying the same in security.json in the following manner:
{
"authorization": {
"class": "org.apache.solr.security.MockAuthorizationPlugin",
"other_data" : "..."}
}
注意:这中配置仅仅支持集群模式,而且重新加载授权时需要重启solr服务
也有一个已经实现的授权插件
Available Authorization Plugins
Solr has one implementation of an authorization plugin:
Rule-Based Authorization Plugin
Basic Authentication Plugin
要将security.json上传到zookeeper中
{
"authentication":{
"blockUnknown": true,
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[{"name":"security-edit",
"role":"admin"}],
"user-role":{"solr":"admin"}
}}
Basic authentication and rule-based authorization plugins are enabled.
A user called 'solr', with a password has been defined.
Unauthenticated requests are not allowed to pass through
The 'admin' role has been defined, and it has permission to edit security settings.
The 'solr' user has been defined to the 'admin' role.
基本安全和基本规则插件要被启用
一个用户solr,密码要被定义
未认证的请求不允许访问
定义了admin角色,有权限修改安全设置
solr用户被定义为admin用户
Editing User Details(编辑用户信息)
An Authentication API allows modifying user IDs and passwords.
The API provides an endpoint with specific
commands to set user details or delete a user.
认证API允许去修改用户的id和密码.这个API提供了指定的命令去设置用户详细信息及
删除一个用户.
API Entry Point(API的入口)
admin/authentication
This endpoint is not collection-specific, so users are created for the entire Solr cluster.
If users need to be
restricted to a specific collection,
that can be done with the authorization rules.
这里没有指定集合,所以用户能够操作整个solr集群 ,如果使用者想去限制指定的集合,那么
可以在授权规则中去设置.
下面是添加,删除,及solrJ连接的例子(493和494)
solr集群中节点之间的通信请求是以超级用户的身份进行的(节点自己识别)
PKIAuthenticationPlugin
任何两个节点之间通过,公钥和密钥来进行身份验证,并且通信的信息中携带了时间戳,
如果超过5s那么就失败了,这里默认两个节点之间的时间是同步的.可以在启动solr时
设置过期时间
'-Dpkiauth.ttl=10' 为10s过期
Kerberos Authentication Plugin
原理好像是字典表的模式--具体可看文档
下面是协议的参考资料
配置使用:
同样是配置
security.json文件上传到zookeeper中
还有一个系统配置的方式
-DauthenticationPlugin=org.apache.solr.security.KerberosPlugin
单机版本仅仅只能使用这个模式,集群模式建议使用配置文件的方式
Kerberized ZooKeeper
看这个例子:
starting Zookeeper in Kerberos mode
Browser Configuration
对于浏览器访问UI界面,有些浏览器是不支持的入谷歌.如果支持的话,看看你的电脑如何去
设置系统管理员的kerberized来访问UI界面
Plugin Configuration(配置插件)
Configuration of the Kerberos plugin has several parts:
Create service principals and keytab files
ZooKeeper configuration
Create or update /security.json
Define jaas-client.conf
Solr startup parameters
配置kerberos插件要有以下几个部分:
创建服务主体和字典密码文件
zookeeper的配置
创建或者更新secutity.json
定义jass连接配置
solr的启动参数
具体实例见(496-500)
Rule-Based Authorization Plugin(基本授权规则插件)
solr允许配置规则来控制用户访问系统.能够通过规则对用户进行权限的分配
角色的权限是可以定制的如访问一个特定的集合,请求处理器,请求参数和请求方法
Enable the Authorization Plugin(启用权限控制插件)
上传security.json到zookeeper中
下面是一个Basic authentication plugin + Rule-Based Authorization Plugin 插件的例子
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[{"name":"security-edit",
"role":"admin"}]
"user-role":{"solr":"admin"}
}}
例子的解释:
Basic authentication and rule-based authorization plugins are enabled.
A user called 'solr', with a password has been defined.
All requests w/o credentials will be rejected with a 401 error. Set 'blockUnknown' to false (or remove it
altogether) if you wish to let unauthenticated requests to go through. However, if a particular resource is
protected by a rule, they are rejected anyway with a 401 error.
The 'admin' role has been defined, and it has permission to edit security settings.
The 'solr' user has been defined to the 'admin' role.
大部分和上文中的一致,只有
"blockUnknown": true,是当无访问权限时显示401错误.
今天先到这里,mark一下到501页.
---------------------------
Permission Attributes(权限属性)
●改变配置可能会导致solr启动失败或者不在预料中的行为
●
恶意软件发现进入您的系统。
●
控制哪些ACLs Solr将增加zookeeper节点(zookeeper文件/文件夹)它在zookeeper创建。
●
schema是“digest”。用户名和密码分别被定义为系统属性的用户名和密码
●
org.apache.solr.common.cloud.DefaultZkACLProvider:
每个用户又一个或者几个权限组成,每个权限由几个定义过可以做哪些事的属性组成.
下面有一些不能被修改的预定义权限:
Pre-defined Permissions
有一些预定义的权限。这些固定的默认值,不能修改,无法添加新属性。要使用这些属性,只需定义一个角色,包括这个权限, 然后给一个用户分配角色。
security-edit:
该许可允许编辑安全配置,这意味着任何更新的操作修改security.json 通过api将被允许.
security-read:
该许可允许阅读安全配置,这意味着任何行动来读取security.json 通过api将被允许。
schema-edit:
该许可允许编辑集合的schema使用schema API .
请注意,这个 schema edit 权限 是适用于全部集合的.
如果要只能编辑指定的集合的schema,应该去创建一个自定义的权限.
schema-read:
该许可允许读取集合的schema使用schema API .
请注意,这个 schema edit 权限 是适用于全部集合的.
如果要只能读取指定的集合的schema,应该去创建一个自定义的权限.
config-edit:
该权限允许去编辑集合的配置信息使用 config API ,request Parameters API
或者其他能够修改configoverlay.json的API.
注意,这个权限允许去修改全部的集合的配置信息.
如果要只能编辑指定的集合的配置信息,应该创建一个新的权限。
config-read:
该权限允许去查看集合的配置信息使用 config API ,request Parameters API
或者其他能够修改configoverlay.json的API.
注意,这个权限允许去查看全部的集合的配置信息.
如果要只能查看指定的集合的配置信息,应该创建一个新的权限。
collection-admin-edit:
该许可允许使用 Collections API 来修改集合的配置.
注意,这个权限允许去编辑所有的集合.
如果要只能编辑指定的集合,应该创建一个自定义的权限.
具体来说,下列的Collection API 将被允许:
CREATE
RELOAD
SPLITSHARD
CREATESHARD
DELETESHARD
CREATEALIAS
DELETEALIAS
DELETE
DELETEREPLICA
ADDREPLICA
CLUSTERPROP
MIGRATE
ADDROLE
REMOVEROLE
ADDREPLICAPROP
DELETEREPLICAPROP
BALANCESHARDUNIQUE
REBALANCELEADERS
collection-admin-read:
该许可允许使用 Collections API 来查看集合的配置.
注意,这个权限允许去查看所有的集合.
如果要只能查看指定的集合,应该创建一个自定义的权限.
具体来说,下列的Collection API 将被允许:
LIST
OVERSEERSTATUS
CLUSTERSTATUS
REQUESTSTATUS
update:
这个权限允许去执行任何更新操作对于所有的集合.
包含发送文档索引(使用 一个 update request handler)
read:
这个权限允许执行任何读取操作对于所有集合
包含使用搜索处理器的查询(使用 request handlers)
像 /select, /get, /browse, /tvrh, /terms, /clustering,
/elevate, /export, /spell, /clustering, /sql.
all:
任何经过solr的请求
Authorization API(权限操作 API)
API Endpoint
/admin/authorization:
需要一组命令去创建权限,映射权限到角色,映射角色到用户
Manage Permissions(权限管理)
三个命令来进行权限管理:
set-permission:
创建一个新的权限,覆盖现有的权限定义,或者分配一个预定义权限给角色
update-permission:
更新已有的权限定义的一些属性
delete-permission:
删除一个权限
=====
如果你不使用上面预定义的权限,那么需要去创建一个权限.
下面几个属性可以用于你自定义的权限.
name:
权限的名字。这个名字将被用于更新或删除权限。
collection:
这个权限将被应用于集合或者所有集合.
当这个路径是被允许的特定集合时,像当设置权限允许使用Schema API,省略集合的属性
将允许去定义 路径 and/or 方法 对于所有的集合.
然而,当路径是non-collection-specific,像这样 Collection API 这个集合的值必须为null
path:
请求处理器的名称,像 /update or /select .支持通配符,去允许全部的路径(想 /update/*)
method:
这个参数用来控制HTTP的请求方法.
你可以只允许GET请求,或者有一个的角色,允许PUT和POST请求。
该方法允许这个属性的值GET、POST、PUT、DELETE和HEAD。
params:
请求参数的名称和值。
如果所有请求参数都被允许的,这个属性可以省略.
如果定义,只会限制访问提供的值。
例如,这个属性可以用来限制操作的作用是只允许执行Collection API。
如果这个角色应该只被允许执行LIST或CLUSTERSTATUS列表请求,您将定义如下
"params": {
"action": [LIST, CLUSTERSTATUS]
}
before:
此属性允许权限排序。此属性的值为
这个新的许可权限应放在security.json。
role:
角色(s)的名字给这个许可。
这个名字将被用于用户id映射到角色授予这些权限。
意思是可以通配符(*),这意味着任何用户都可用,但没有用户并不好。
下面将创建一个新的名为collection-mgr的权限,允许创建集合和 查看集合列表。
许可将被放置在"读的许可。还请注意,我们已经定义了“集合为空,
这是因为请求Collections API永远不会与特定集合有关。
curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
"set-permission": {"name":"collection-mgr",
"collection": null,
"path":"/admin/collections",
"params":{"action":[LIST, CREATE]},
"before": "read",
"role": "admin"}
Map Roles to Users
A single command allows roles to be mapped to users
一行命令允许映射角色到用户
set-user-role: 映射一个用户到一个权限
删除用户的权限,您应该将角色设置为null。没有命令来删除一个用户角色。
这个命令提供仅仅是用户ID和用户应该有一个或多个角色。
例如,下面将授予用户“solr”“admin”和“dev”的角色,
并删除所有的角色用户ID“harry”:
Enabling SSL(启用SSL)
SolrCloud和单节点Solr都可以加密通信对于连接,和SolrCloud的节点,使用SSL。
本节描述启用SSL Jetty服务器使用一个自签名证书的例子。
SSL证书和密钥的介绍,请参阅
主要包含以下及部分内容
基本的SSL设置
Generate a self-signed certificate and a key
● 生成一个自签名证书和一个密钥
● 证书和密钥转换为PEM格式使用cURL
● 设置通用SSL相关系统的属性
● 单节点运行Solr使用SSL
SolrCloud
●配置 Zookeeper
●使用SSL运行SolrCloud
客户端操作的例子
创建一个SolrCloud Collection 使用bin / solr
使用cURL查看 solrCloud集群状态
使用post.jar建立文档索引
使用cURL查询
使用CloudSolrClient索引一个文档
Basic SSL Setup
Generate a self-signed certificate and a key
生成一个自签名证书和一个key,进行身份验证,在服务器和连接之间,我们将使用JDK keytool命令和创建一个单独的密钥存储库。
这个密钥库也将用作下面一个信任存储库。
可以使用的密钥存储库的JDK的目的,和使用单独的信任存储库,但是这些选项不覆盖。
运行下面的命令在server/ etc /目录中的binary Solr分布。
假设您有JDK keytool工具在你的路径,openssl也在你的路径。
“-ext SAN=…“keytool选项允许您指定的所有DNS名称和/或IP地址允许在主机名验证(但见下文如何跳过主机名验证Solr节点之间,你不需要在这里指定所有主机)。
除了本地主机127.0.0.1,这个例子包括局域网IP地址192.168.1.3 Solr的机器节点上运行:
keytool -genkeypair -alias solr-ssl -keyalg RSA -keysize 2048 -keypass secret
-storepass secret -validity 9999 -keystore solr-ssl.keystore.jks -ext
SAN=DNS:localhost,IP:192.168.1.3,IP:127.0.0.1 -dname "CN=localhost,
OU=Organizational Unit, O=Organization, L=Location, ST=State, C=Country"
上面的命令将创建一个名为solr-ssl.keystore.jks 的keystore文件,在当前目录中。
Convert the certificate and key to PEM format for use with cURL
cURL不能够使用JKS格式化的密钥存储库,所以JKS密钥存储库需要转换成PEM格式, 使cURL能够理解。
首先将使用keytool JKS密钥存储库到PKCS12格式
keytool -importkeystore -srckeystore solr-ssl.keystore.jks -destkeystore
solr-ssl.keystore.p12 -srcstoretype jks -deststoretype pkcs12
keytool应用程序将提示您创建一个目的地keystore密码和密钥存储库 密码,设置创建密钥存储库时(“secret ”在上面的示例中)。
接下来将PKCS12格式密钥存储库,包括证书和密钥,使用openssl命令转为PEM格式
openssl pkcs12 -in solr-ssl.keystore.p12 -out solr-ssl.pem
如果你想使用cURL在OS X Yosemite(10.10),
您需要创建一个certificate-only版本的PEM 格式,如下:
openssl pkcs12 -nokeys -in solr-ssl.keystore.p12 -out solr-ssl.cacert.pem
Set common SSL related system properties
Solr开始脚本已经设置SSL-related Java系统属性传递给JVM。
为了激活SSL设置,取消和更新这组属性开始在bin / solr.in.sh SOLR_SSL_ *。
(或bin\solr.in.cmd在 windows中)。注意,如果你设置了solr作为服务在linux中使用
这个概述中 Taking Solr to Production,在 /var/solr/solr.in.sh中进行这些更改
bin/solr.in.sh example SOLR_SSL_* configuration
SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_KEY_STORE_PASSWORD=secret
SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
SOLR_SSL_TRUST_STORE_PASSWORD=secret
# Require clients to authenticate
SOLR_SSL_NEED_CLIENT_AUTH=false
# Enable clients to authenticate (but not require)
SOLR_SSL_WANT_CLIENT_AUTH=false
When you start Solr, the bin/solr script includes the settings in bin/solr.in.sh and will pass these SSL-related system properties to the JVM.
当你启动Solr,bin/Solr脚本包括在bin/solr.in.sh中的设置。
并将这些SSL-related系统属性传递给JVM。
注意连接设置:
使SOLR_SSL_NEED_CLIENT_AUTH或SOLR_SSL_WANT_CLIENT_AUTH
但并不在同一时间。他们是相互排斥的,jetty将选择其中一个,可能不是你希望的
同样的,当你启动Solr,bin/Solr.cmd脚本包括在bin/solr.in.sh.cmd中的设置。
并将这些SSL-related系统属性传递给JVM。
bin\solr.in.cmd example SOLR_SSL_* configuration
set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.jks
set SOLR_SSL_KEY_STORE_PASSWORD=secret
set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.jks
set SOLR_SSL_TRUST_STORE_PASSWORD=secret
REM Require clients to authenticate
set SOLR_SSL_NEED_CLIENT_AUTH=false
REM Enable clients to authenticate (but not require)
set SOLR_SSL_WANT_CLIENT_AUTH=false
Run Single Node Solr using SSL
使用如下所示的命令启动Solr;默认情况下连接不需要身份验证
*nix command
bin/solr -p 8984
Windows command
bin\solr.cmd -p 8984
SolrCloud
本节描述如何运行一个两节点集群SolrCloud,没有初始化集合和一个单节点外的zookeeper。下面的命令假设您已经创建了密钥存储库。
Configure ZooKeeper
在你开始任何SolrCloud节点之前,您必须配置您的solr集群属性在zookeeper,
以便Solr节点知道通过SSL通信。
本节假设您已经创建了,开始单节点的外部zookeeper在本地主机端口2181上
—see Setting Up an External ZooKeeper Ensemble
urlScheme整个集群范围的属性需要被设置为https,在任何Solr节点启动之前。
这个下面这个例子使用的zkcli工具 二进制Solr分布:
*nix command
server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd clusterprop
-name urlScheme -val https
Windows command
server\scripts\cloud-scripts\zkcli.bat -zkhost localhost:2181 -cmd clusterprop
-name urlScheme -val https
如果你有设置集群zookeeper使用chroot Solr,确保您的zkcli使用正确的zkhost字符串,
例如-zkhost localhost:2181 / solr。
Run SolrCloud with SSL
Create Solr home directories for two nodes
创建两个副本的server/solr /目录将作为solr home 目录,对于两个SolrCloud节点:
*nix commands
mkdir cloud
cp -r server/solr cloud/node1
cp -r server/solr cloud/node2
Windows commands
mkdir cloud
xcopy /E server\solr cloud\node1\
xcopy /E server\solr cloud\node2\
Start the first Solr node
接下来,开始第一个Solr节点在端口8984上。
首先一定要停止单机服务如果你开始工作时通过一节在这个页面。
*nix command
bin/solr -cloud -s cloud/node1 -z localhost:2181 -p 8984
Windows command
bin\solr.cmd -cloud -s cloud\node1 -z localhost:2181 -p 8984
注意使用-s 选项设置为node1 的 Solr home目录的位置。
如果你创建SSL密钥没有DNS名称/ IP地址,在将运行Solr节点,你可以告诉Solr跳过
主机名称校验对于 inter-solr-node(节点间)通讯,设置 solr.ssl.checkPeerName 系统
属性为false;
*nix command
bin/solr -cloud -s cloud/node1 -z localhost:2181 -p 8984
-Dsolr.ssl.checkPeerName=false
Windows command
bin\solr.cmd -cloud -s cloud\node1 -z localhost:2181 -p 8984
-Dsolr.ssl.checkPeerName=false
Start the second Solr node
最后,在端口7574上启动第二个Solr节点——再一次,
跳过主机名验证,添加 -Dsolr.ssl.checkPeerName = false;
*nix command
bin/solr -cloud -s cloud/node2 -z localhost:2181 -p 7574
Windows command
bin\solr.cmd -cloud -s cloud\node2 -z localhost:2181 -p 7574
Example Client Actions
Create a SolrCloud collection using bin/solr
创建一个2-shard,replicationFactor = 1 名称为mycollection 使用默认的配置文件
(data_driven_schema_configs):
*nix command
bin/solr create -c mycollection -shards 2
Windows command
bin\solr.cmd create -c mycollection -shards 2
创建操作将通过SOLR_SSL_ * 属性 开始你包含的文件去solrJ代码使用创建这个集合。
Retrieve SolrCloud cluster status using cURL
能获取的集群状态(如果你没有启用客户端身份验证,移除 -E solr-ssl.pem:secret 选项):
curl -E solr-ssl.pem:secret --cacert solr-ssl.pem
你应该得到这样的响应:
{
"responseHeader":{
"status":0,
"QTime":2041},
"cluster":{
"collections":{
"mycollection":{
"shards":{
"shard1":{
"range":"80000000-ffffffff",
"state":"active",
"replicas":{"core_node1":{
"state":"active",
"base_url":"
https://127.0.0.1:8984/solr",
"core":"mycollection_shard1_replica1",
"node_name":"127.0.0.1:8984_solr",
"leader":"true"}}},
"shard2":{
"range":"0-7fffffff",
"state":"active",
"replicas":{"core_node2":{
"state":"active",
"base_url":"
https://127.0.0.1:7574/solr",
"core":"mycollection_shard2_replica1",
"node_name":"127.0.0.1:7574_solr",
"leader":"true"}}}},
"maxShardsPerNode":"1",
"router":{"name":"compositeId"},
"replicationFactor":"1"}},
"properties":{"urlScheme":"https"}}}
Index documents using post.jar
使用post.jar去索引一些实例文档到上文创建的solrcloud collection中
cd example/exampledocs
java -Djavax.net.ssl.keyStorePassword=secret
-Djavax.net.ssl.keyStore=../../server/etc/solr-ssl.keystore.jks
-Djavax.net.ssl.trustStore=../../server/etc/solr-ssl.keystore.jks
-Djavax.net.ssl.trustStorePassword=secret
-Durl=
https://localhost:8984/solr/mycollection/update -jar post.jar *.xml
Query using cURL
使用cURL来查询上面创建的SolrCloud collection,从一个目录包含PEM格式上面创建证书和密钥(如 example/etc/)——如果你没有启用客户端身份验证(系统参数-Djetty.ssl.clientAuth = true),那么您可以删除-E solr-ss.pem:secret 选项:
curl -E solr-ssl.pem:secret --cacert solr-ssl.pem
"
https://localhost:8984/solr/mycollection/select?q=*:*&wt=json&indent=on"
Index a document using CloudSolrClient
对于使用solrJ来连接,创建文档索引.在下列的代码中,javax.net.ssl.* 系统参数是在程序中进行设置的.但是 你能使用java 命令行来代替他 向上文 post.jar 例子.
System.setProperty("javax.net.ssl.keyStore", "/path/to/solr-ssl.keystore.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "secret");
System.setProperty("javax.net.ssl.trustStore", "/path/to/solr-ssl.keystore.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "secret");
String zkHost = "127.0.0.1:2181";
CloudSolrClient server = new CloudSolrClient(zkHost);
server.setDefaultCollection("mycollection");
SolrInputDocument doc = new SolrInputDocument();
doc.addField("id", "1234");
doc.addField("name", "A lovely summer holiday");
server.add(doc);
server.commit();
--------------------------
ZooKeeper Access Control(zookeeper 访问控制)--530-535
这部分描述的是使用zookeeper的访问控制列表(ACLs)对于solr.有关zookeeper ACLs的信息 ,可以看zookeeper的文档:
http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#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,你也许想去在代码级别去替代复写提供的接口的实现.
转自:http://blog.csdn.net/sqh201030412/article/details/51253819