janhoy commented on issue #594:
URL: https://github.com/apache/solr-operator/issues/594#issuecomment-6480299202
Three different situations ended up in this thread, so to close it out:
**@rekhasinghcali** — one secret was used for both `bootstrapSecurityJson`
and `basicAuthSecret`. They must be two separate secrets: `basicAuthSecret` is
a `kubernetes.io/basic-auth` secret with `username`/`password`, while
`bootstrapSecurityJson` points at an Opaque secret plus the key holding the
file contents.
**@mlanner** — `key` is simply the key *inside* that Opaque secret whose
value is the `security.json` content. It doesn't reference a file in ZooKeeper;
the operator reads that key and an init container uploads the value to
`/security.json` under your chroot.
**@liseli** — this is almost certainly the bootstrap-only limitation. The
init container uploads your `security.json` only when the one in ZooKeeper is
absent, empty, or `{}` (`controllers/util/solr_security_util.go:242-254`).
Since plain `authenticationType: Basic` had already run, ZooKeeper held the
operator-generated file and yours was never applied. Clear it with `kubectl
exec <pod> -- solr zk rm <chroot>/security.json` and restart a pod. Making
updates propagate is tracked in #488, with #744 in flight.
Docs:
https://solr.apache.org/guide/operator/latest/solr-cloud/authentication-and-authorization.html
— closing, since each case is either answered or tracked elsewhere. Please
open a fresh issue with your spec, both secret shapes and the pod state if you
believe there's still a bug.
--
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]
