The security.json that the Solr operator creates during security boostrapping when using:
spec:
...
solrSecurity:
authenticationType: Basic
Grants the all permission to the users role.
I misinterpreted this permission to mean all endpoints unless specifically overridden by another rule, which is how it works but seems to be order dependent. If this "all" permission is listed last, then we get the behavior I intended. But if it's listed before the more restrictive rules, then it takes precedence and allows broader access than I intended for the default authz rules. Upon further reflection, I think the operator should not assign the users role to the all permission at all, so the change looks like:
diff --git a/controllers/util/solr_util.go b/controllers/util/solr_util.go
index c8f3b05..fbc9d0e 100644
--- a/controllers/util/solr_util.go
+++ b/controllers/util/solr_util.go
@@ -1387,7 +1387,7 @@ func generateSecurityJson(solrCloud *solr.SolrCloud) map[string][]byte {
{ "name": "k8s-status", "role":"k8s", "collection": null, "path":"/admin/collections" },
{ "name": "k8s-metrics", "role":"k8s", "collection": null, "path":"/admin/metrics" },
{ "name": "k8s-ping", "role":"k8s", "collection": "*", "path":"/admin/ping" },
- { "name": "all", "role":["admin","users"] },
+ { "name": "all", "role":["admin"] },
{ "name": "read", "role":["admin","users"] },
{ "name": "update", "role":["admin"] },
{ "name": "security-read", "role": "admin"},
The work-around for users that have already bootstrapped a SolrCloud with basic-auth enabled is to manually update their security.json to remove users from the all role. You can do this using the zkcli.sh script to update the security.json directly:
./zkcli.sh -zkhost $ZK_HOST -cmd putfile /security.json $SOME_LOCAL_PATH/security.json
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4