What

We should investigate the use of an operator to create keycloak instances and distribute credentials to end users without exposing information about those instances.

Why

The end user should be abstracted from the keycloak setup and should not be exposed to anymore information about it that extends using it as an end user

How

Operator will exist within a namespace and will watch across other namespaces fro creation of a named CRD. The operator will then create a secret with required information to use keycloak within that namespace. This includes creation of realm, username and password. This provides the user with a "slice" of keycloak service

The operator will load its config which should have a min and max value for keycloak instances
which it will create at startup. Excess instances should be scaled down until needed.

An additional CRD can be created to create a public client. This will create another secret. A slice must be requested before this is granted however. Possibly this operator also ensures the data in the secrets is in sync with the data in the keycloak

Possible things to leverage:
1. Package bundle-lib to see if we can execute our existing apbs - if not move it into the code
2. Share the mysql database across instances