Currently, the RHBK Operator uses secret/example-kc-initial-admin for the Admin username and password. This prevents customers from implementing a more secure way of accessing the Admin Console through SealedSecret or ExternalSecret objects.

We need to provide support for Kubernetes Secrets Store CSI Driver in Operator for User-provided Secrets, as per GHI#15830

External Secrets are referenced in the OpenShift Documentation and also Red Hat Blog Posts, although both seem to differ on the approaches (and the customer seemed to have mentioned the latter).

Since RH SSO / RHBK are solutions to provide enhanced security for our customers, it makes sense that they are able to rely on better security mechanisms to define the initial admin username and password.
It's unknown at the moment whether the best approach would be to reference a different Secret (not managed by the Operator), files mounted from a Secret or both. This will depend on the future ability from the Operator to mount Secrets as files again without the "unsupported" approach and whether we want to cover an External Secrets Store, External Secrets Operator (ESO) or both, assuming the Secrets from ESO can be mounted as files.
For SealedSecret, it seems like the solution to External Secrets would already address them as well.