thelabdude opened a new issue #218: URL: https://github.com/apache/lucene-solr-operator/issues/218
For background on Solr basic auth, see: https://lucene.apache.org/solr/guide/8_8/basic-authentication-plugin.html#basic-authentication-plugin The Solr operator should provide an easy way to enable basic authentication for a SolrCloud cluster. There are two main uses cases we should support: 1. The operator should bootstrap a default `security.json` with basic auth enabled. This allows users to easily spin-up a secure Solr cluster without having to know all the details of how Solr security works. 2. The operator should allow users to supply their own `security.json` (via ConfigMap) and corresponding secret with credentials the operator should use to make API requests to Solr. When basic auth is enabled, we need to ensure the liveness / readiness probes work (`/admin/info/system` endpoint). In addition, the rolling restart logic requires access to the `/admin/collections` endpoint. Also, backup / restore requires API access. Thus, the Solr operator needs access to a username and password to make API calls. These credentials will come from a Kubernetes secret in the same namespace. For the first use case (bootstrap a default config), the only tricky part is we need to create the user password hashes in the same manner that Solr expects them. The default `security.json` will define an `admin` user, a general purpose read-only `solr` user, and special `k8s-oper` user that *only* has read access to the API endpoints needed to operator in Kubernetes, such as the `/admin/info/system` endpoint used by probes. The password for each user can be retrieved using `kubectl` using: ``` kubectl get secret dev-solrcloud-basic-auth -o jsonpath='{.data.k8s-oper}' | base64 --decode ``` Also, I'm not sure if the operator should watch the `security.json` ConfigMap for updates (as we do with other user-provided ConfigMaps) and try to apply the updated JSON? There's an API for updating the security config and the ref guide suggests using that so maybe the operator just bootstraps the file and then it's up to users to maintain via the API? For the probes, K8s allows specifying a header for HTTP endpoints, but then our password will live in the STS config. I think it would be better to set an env var from the secret and then run a command for the probe using this env var. The SolrCLI command-line tool provides an `api` action that we can use for the probes: ``` java -Dbasicauth=k8s-oper:****** \ -Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory \ -Dsolr.install.dir="/opt/solr" \ -Dlog4j.configurationFile="/opt/solr/server/resources/log4j2-console.xml" \ -classpath "/opt/solr/server/solr-webapp/webapp/WEB-INF/lib/*:/opt/solr/server/lib/ext/*:/opt/solr/server/lib/*" \ org.apache.solr.util.SolrCLI api -get http://localhost:8983/solr/admin/info/system ``` Unfortunately, `bin/solr` does not expose the `api` action :-( ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
