The Operator already has support for configuring Solr with BasicAuth, and the Operator is given BasicAuth credentials to be able to access /solr/admin/info/system, /solr/admin/collections and /solr/admin/{backup,restore}.

The operator should also work when JWTAuthPlugin is used for the cluster. The Operator will then need to obtain and use a JWT token as an Authorization: Bearer xxxx header for all requests to Solr endpoints, analogous to how it uses Authorization: Basic xxxx today.

What I propose is

• Operator can be configured to setup security.json for JWT
• Operator can be configured to obtain a JWT token from an OIDC server to talk to Solr

The security.json is not that different from the BasicAuth one, something like:

{
  "authentication": {
    "blockUnknown": false,
    "class": "solr.JWTAuthPlugin",
    "redirectUris": "https://my.solr.server:8983/solr/,https://my.other.solr.server:8983/solr/",
    "rolesClaim": "roles",
    "issuers": [
      {
        "wellKnownUrl": "https://idp.example.com/.well-known/openid-configuration",
        "clientId": "<MY_CLIENT_ID>",
      }
    ]
  },
  "authorization": {
    "class": "solr.ExternalRoleRuleBasedAuthorizationPlugin",
    "permissions": [ ... ]
  }
}

The permissions will mostly be the same, and the mapping from users to their roles will happen in the OIDC server, so we'll not care about usernames in security.json, just roles. To generate this, we need some more config values to operator:

spec:
  ...
  solrSecurity:
    authenticationType: JWT
    jwt:
      wellKnownUrl: <url>
      solrClientId: <solr client-id as registered with OIDC>
      rolesClaim: <jwt claim key where role name is stored>
      oper-role: k8s
      admin-role: admin
      operClientId: <operator client-id as registered with OIDC>
      operClientSecretName: <name of k8s secret where operator's client secret for OIDC is stored>

The user will ahead of time register Solr and SolrOperator with OIDC server to obtain client-ID and secret. The Operator will generate and provision security.json and connect to OIDC's token endpoint to obtain a JWT token for Solr.

The user should probably also be able to provision security.json manually, and in that case, only wellKnownUrl, operClientId and operClientSecretName would need to be configured. If users have more advanced JWT config needs than the basics above, such as multiple issuers, then a manual approach is better than bloating the operator with every single option.