HoustonPutman commented on issue #331:
URL: https://github.com/apache/solr-operator/issues/331#issuecomment-931488112
I think it would be great for a user to provide a custom configMap for their
security.json, or a secret for that matter (since it might have sensitive
information).
```yaml
spec:
solrSecurity:
authenticationType: <type>
bootstrapSecurityJson: <requires key and either secret or configMap>
secret: <optional>
configMap: <optional>
key: <defaults to security.json>
```
Researching this comment, it turns out there are a lot of options when
configuring the JWT plugin, and what we would be doing is basically just
templating the json for them. So maybe just allowing a configMap or secret
would be the right way to go.
Honestly there isn't really a need to differentiate things at some point if
they are doing a custom security JSON. we just need an authorization header to
send to Solr. So `authenticationType` could be `Basic` or `Bearer`.
```yaml
spec:
...
solrSecurity:
authenticationType: Bearer
bootstrapSecurityJson:
configMap: <user-supplied config map>
key: <defaults to security.json>
oidc:
clientId: <operator client-id as registered with OIDC>
clientSecret: <name and key of k8s secret where operator's client
secret for OIDC is stored>
bearerTokenSecret: <just a plain secret with a JWT token to use that is
already setup by the user>
```
For the OIDC option, would the operator have to go fetch the JWT string to
use every time by getting the oidc wellKnownUrl from the secret/configMap, then
sending a request to that url with the provided ID and secret? I'm not familiar
with oidc, so not exactly sure how that process works. I left it in there as an
option, since it seemed more complicated than just using a predefined secret
with a JWT token.
Not sold on this, just my thoughts currently.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
