drewburr commented on issue #488: URL: https://github.com/apache/solr-operator/issues/488#issuecomment-1421121981
Wanted to piggyback on this conversation with a process used elsewhere to help knowledge-share and maybe draw some inspiration. My organization uses the [CrunchyData Operator for Postgres](https://access.crunchydata.com/documentation/postgres-operator/5.3.0/) which includes [custom user creation](https://access.crunchydata.com/documentation/postgres-operator/5.3.0/architecture/user-management/), permission mapping, and password rotation strategies for the database users. Here is the related [CRD reference](https://access.crunchydata.com/documentation/postgres-operator/5.3.0/references/crd/#postgresclusterspecusersindex) for context. On the PostgresClusters object, the spec for user specification looks similar to: ```yaml apiVersion: postgres-operator.crunchydata.com/v1beta1 kind: PostgresCluster metadata: name: my-postgrescluster spec: users: - name: app-user options: LOGIN CREATEDB - name: readonly-user options: LOGIN password: AlphaNumeric - name: permissions-user options: CREATEROLE ``` This operator stores credential information in secrets using the following format: ```<postgres-name>-pguser-<username>``` which could be translated to something like the below for Solr: ```<solr-name>-solrcloud-user-<username>``` ...and these secrets contain the following information: ``` { "host": "service-name.namespace.svc", "password": "cleartext-password", "port": "5432", "user": "username", "verifier": "hashed/encrypted password" } ``` What is interesting about this process is the use of the `verifier` value. Like Solr, Postgres has a file containing hashed/encrypted passwords. The Operator uses the verifier value to check if the correct password is configured. If there is a mismatch, the Operator will apply the password from the Secret and overwrite the verifier value. This behavior provides a way to force a password re-apply, by deleting or clearing the verifier value. For password rotations, we update the value of `password` and clear the verifier value, which allows the operator to handle rotation for us. ----- What I'm really interested in is going as far as fully abstracting the security.json file into the Solr CRD and Operator functions. Here's a spec that could potentially be used to generate a security.json for basic auth. Considering there are very different needs for different authentication plugins, also I chose to separate basic auth configuration from the ability to specify a configMap/secret/string for the security.json file ```yaml spec: solrSecurity: # Reference to secret with security.json. Mutually exclusive with solrBasicAuth. # secret, configMap, and value are mutually exclusive secret: name: # Name of secret key: # secret key containing security.json configMap: name: # Name of configMap key: # configMap key containing security.json value: # String representing security.json (if this support is desired) solrBasicAuth: # Abstracted security.json file. Mutually exclusive with solrSecurity. blockUnknown: false users: solr: roles: [ admin ] custom-user: roles: [ custom-role ] roles: # Potentially optional. Could be generated dynamically from users[].*.roles[] and permissions[].*.roles[] foobar-role: users: [ custom-user ] # Required permissions: [] # Optional permissions: security-edit: roles: - admin custom-permission: roles: [ custom-role ] collection: * path: /admin/ping methods: GET params: key: value ``` Personally, I see a lot of value in being able to manage all users, credentials, and permissions from the Solr/SolrCloud objects. Today, we have a post-install process that configures additional users and permissions via the Solr API, which is less than ideal for a situation where we need to fully rebuild or replicate an installation. Our process also creates opportunities for users to be created and credentials to be rotated but not stored in our password manager application, due to user error. It also prevents us from handling automatic credential rotation and propagation to other platforms - something that would be possible if user credentials were stored as secrets. I'm curious to know what your thoughts are about this level of Operator integration, and if there's interest in moving in such a direction. I'm also happy to have a continued conversation on this topic. Thank you! -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
