You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by Paul Ryder <pa...@greenwaymediatech.com> on 2023/03/20 16:19:11 UTC
Solr Security - Replication
Hi All
I've manage to configure my security.json so that a read only user can access the admin panel but not update any docs or create/edit collections... security.json is as below
One thing they *can* do, which I'd rather they couldn't, is click the "Disable Replication" button on the core replication screen and disable the replication... Any idea how to disable this for a given user/role?
Ta! Paul
{
"authentication":{
"blockUnknown":true,
"class":"solr.BasicAuthPlugin",
"credentials":{
"solr-admin":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
"solr-read":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="},
"forwardCredentials":false,
"":{"v":0}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"user-role":{
"solr-admin":["admin"],
"solr-read":["readonly"]},
"permissions":[
{
"name":"update",
"role":[
"admin"],
"index":1},
{
"name":"read",
"role":[
"admin",
"readonly"],
"index":2},
{
"name":"security-edit",
"role":["admin"],
"index":3},
{
"name":"security-read",
"role":["admin"],
"index":4},
{
"name":"core-admin-edit",
"role":["admin"],
"index":5},
{
"name":"collection-admin-edit",
"role":["admin"],
"index":6},
{
"name":"config-edit",
"role":["admin"],
"index":7},
{
"name":"config-read",
"role":["admin"],
"index":8},
{
"name":"schema-edit",
"role":["admin"],
"index":9},
{
"name":"filestore-write",
"role":["admin"],
"index":10},
{
"name":"package-edit",
"role":["admin"],
"index":11},
{
"name":"all",
"role":[
"admin",
"readonly"],
"index":12}],
"":{"v":0}}}
Re: Solr Security - Replication
Posted by Paul Ryder <pa...@greenwaymediatech.com>.
Hi Shawn
Excellent answer as always….
Ta! Paul
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Shawn Heisey <ap...@elyograg.org>
Sent: Monday, March 20, 2023 7:30:28 PM
To: users@solr.apache.org <us...@solr.apache.org>
Subject: Re: Solr Security - Replication
On 3/20/23 10:19, Paul Ryder wrote:
> I've manage to configure my security.json so that a read only user can access the admin panel but not update any docs or create/edit collections... security.json is as below
<snip>
> {
> "name":"all",
> "role":[
> "admin",
> "readonly"],
> "index":12}
That section is most likely the problem. You gave the readonly role the
"all" permission. Which means if the permission is not explicitly
listed in the prior rules, the readonly role will be allowed to do it.
Remove readonly from the all permission. That might fix it. I don't
think there is an explicit permission that covers enabling or disabling
replication, so it would fall under "all".
Because you have the "all" permission at the end, you do not need any of
the other permissions that have been assigned only to admin, but those
permissions are not hurting anything with the rest of the config the way
it is. The "read" permission DOES need both roles. If you remove admin
from that permission, then the admin user would not be able to do queries.
If you are running in Cloud mode or have a distributed index in
standalone mode, disabling forwardCredentials as you have will most
likely break queries. Someone with more authentication expertise will
need to confirm or refute that statement.
It took me a few hours to fully grasp how the rule-based authorization
in Solr works. Once it clicked, I could see why it was designed to work
that way, which I admit is very non-intuitive. It's enormously flexible.
------------------
Below is a security.json that I constructed entirely in the webui after
uploading the sample authentication and authorization security.json
found in the reference guide to zookeeper. It features three users -
read, update, and admin.
The read role has most of the read permissions found in Solr
9.3.0-SNAPSHOT, plus health. I excluded filestore-read and security-read.
The update role only has the "update" permission. Which means that it
can send update requests.
The admin role has the "all" permission.
The admin user has all three roles. The update user has read and
update. The read user only gets the read role. Due to the way the
config is parsed, if you remove the read and update roles from the admin
user, it won't work the way I envisioned it.
The read user can obtain a large subset of information from Solr but
cannot make changes. The update user can do everything read can do,
plus make changes to the index. The admin user has all permissions.
For better security the read role probably needs a few more permissions
removed, particularly zk-read so only the admin can look directly into
the ZK database. Some experimentation is required.
I have set the coreadmin-edit permission to not allow ANYONE to do it,
as my setup is in cloud mode. Using CoreAdmin to make changes in cloud
mode is a recipe for disaster. It's probably not a good idea in
standalone mode either, but it's FAR less likely to cause BIG problems
in standalone mode.
-----------------
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{
"admin":"REDACTED REDACTED",
"read":"REDACTED REDACTED",
"update":"REDACTED REDACTED"},
"":{"v":153}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
{
"name":"read",
"role":["read"],
"index":1},
{
"name":"collection-admin-read",
"role":["read"],
"index":2},
{
"name":"config-read",
"role":["read"],
"index":3},
{
"name":"core-admin-read",
"role":["read"],
"index":4},
{
"name":"package-read",
"role":["read"],
"index":5},
{
"name":"health",
"role":["read"],
"index":6},
{
"name":"zk-read",
"role":["read"],
"index":7},
{
"name":"schema-read",
"role":["read"],
"index":8},
{
"name":"metrics-read",
"role":["read"],
"index":9},
{
"name":"core-admin-edit",
"role":null,
"index":10},
{
"name":"update",
"role":["update"],
"index":11},
{
"name":"all",
"role":["admin"],
"index":12}],
"user-role":{
"admin":[
"admin",
"read",
"update"],
"read":["read"],
"update":[
"read",
"update"]},
"":{"v":37}}}
Thanks,
Shawn
Re: Solr Security - Replication
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/20/23 10:19, Paul Ryder wrote:
> I've manage to configure my security.json so that a read only user can access the admin panel but not update any docs or create/edit collections... security.json is as below
<snip>
> {
> "name":"all",
> "role":[
> "admin",
> "readonly"],
> "index":12}
That section is most likely the problem. You gave the readonly role the
"all" permission. Which means if the permission is not explicitly
listed in the prior rules, the readonly role will be allowed to do it.
Remove readonly from the all permission. That might fix it. I don't
think there is an explicit permission that covers enabling or disabling
replication, so it would fall under "all".
Because you have the "all" permission at the end, you do not need any of
the other permissions that have been assigned only to admin, but those
permissions are not hurting anything with the rest of the config the way
it is. The "read" permission DOES need both roles. If you remove admin
from that permission, then the admin user would not be able to do queries.
If you are running in Cloud mode or have a distributed index in
standalone mode, disabling forwardCredentials as you have will most
likely break queries. Someone with more authentication expertise will
need to confirm or refute that statement.
It took me a few hours to fully grasp how the rule-based authorization
in Solr works. Once it clicked, I could see why it was designed to work
that way, which I admit is very non-intuitive. It's enormously flexible.
------------------
Below is a security.json that I constructed entirely in the webui after
uploading the sample authentication and authorization security.json
found in the reference guide to zookeeper. It features three users -
read, update, and admin.
The read role has most of the read permissions found in Solr
9.3.0-SNAPSHOT, plus health. I excluded filestore-read and security-read.
The update role only has the "update" permission. Which means that it
can send update requests.
The admin role has the "all" permission.
The admin user has all three roles. The update user has read and
update. The read user only gets the read role. Due to the way the
config is parsed, if you remove the read and update roles from the admin
user, it won't work the way I envisioned it.
The read user can obtain a large subset of information from Solr but
cannot make changes. The update user can do everything read can do,
plus make changes to the index. The admin user has all permissions.
For better security the read role probably needs a few more permissions
removed, particularly zk-read so only the admin can look directly into
the ZK database. Some experimentation is required.
I have set the coreadmin-edit permission to not allow ANYONE to do it,
as my setup is in cloud mode. Using CoreAdmin to make changes in cloud
mode is a recipe for disaster. It's probably not a good idea in
standalone mode either, but it's FAR less likely to cause BIG problems
in standalone mode.
-----------------
{
"authentication":{
"class":"solr.BasicAuthPlugin",
"credentials":{
"admin":"REDACTED REDACTED",
"read":"REDACTED REDACTED",
"update":"REDACTED REDACTED"},
"":{"v":153}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
{
"name":"read",
"role":["read"],
"index":1},
{
"name":"collection-admin-read",
"role":["read"],
"index":2},
{
"name":"config-read",
"role":["read"],
"index":3},
{
"name":"core-admin-read",
"role":["read"],
"index":4},
{
"name":"package-read",
"role":["read"],
"index":5},
{
"name":"health",
"role":["read"],
"index":6},
{
"name":"zk-read",
"role":["read"],
"index":7},
{
"name":"schema-read",
"role":["read"],
"index":8},
{
"name":"metrics-read",
"role":["read"],
"index":9},
{
"name":"core-admin-edit",
"role":null,
"index":10},
{
"name":"update",
"role":["update"],
"index":11},
{
"name":"all",
"role":["admin"],
"index":12}],
"user-role":{
"admin":[
"admin",
"read",
"update"],
"read":["read"],
"update":[
"read",
"update"]},
"":{"v":37}}}
Thanks,
Shawn