Limit default k8s role's access to collection API

[janhoy]

The default security.json generated by the operator has full CollectionAPI access, see https://github.com/apache/solr-operator/blob/84a7781e498a92a66d62eac2a3515c1646bd5ce6/controllers/util/solr_security_util.go#L351

Since the operator typically is using BasicAuth, which is les secure than other auth methods, it could make sense to explicitly limit the actions the k8s role can do on the collection API, i.e. not allow that BasicAuth user to create or delete collections. This can be done by adding params limitation to the custom permission, e.g.

{ 
  "name": "k8s-status", 
  "role":"k8s", 
  "collection": null, 
  "path":"/admin/collections", 
  "params": { 
    "action": ["LIST", "CLUSTERSTATUS", "OVERSEERSTATUS", "BACKUP"] 
  } 
}

[HoustonPutman]

This is a good idea. I think there are some other actions we use, but we can go through and make sure.

One issue is that users could have issues when upgrading the Solr Operator for existing clouds. If the new version of the operator uses more actions, it could fail because existing security.jsons will not be changed to include those actions.

[janhoy]

Yea, upgrading Security.json in general is a hard topic. The init-container that bootstraps security.json does not run if it is already there. But it should ideally be versioned, so that it is gets updated whenever needed during an upgrade?

[HoustonPutman]

Yeah I do like that idea. Maybe if it already exists, we can just merely issue a call to make sure the right stuff is added when the versioning is changed? We can store the version on the statefulset as an annotation. I guess that requires the operator to have super-user permissions, which won't work.

[gerlowskija]

Removing this from the v0.6.0 milestone based on Houston's comment here