h4. What
We should investigate the use of an operator / controller to create shared keycloak instances and distribute credentials to end users without exposing root credentials or unneeded information about those instances.
h4. Why
In a shared service scenario, the end user should be abstracted from the keycloak setup and should not be exposed to anymore information about it that extends beyond using it as an end user
h4. How
Operator will exist within a privileged namespace and will watch across other namespaces fro for 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 in keycloak (similar to what we do know with a provision via the catalog). This provides the user with a "slice" of keycloak service
The A different CRD will be created in the same namespace as the operator called SharedService this will load its config which should have a min number of instances and a max value for keycloak instances
which number of slices allowed, it will create at startup. Excess instances also specify which image should be scaled down until needed.
An additional CRD can be created executed 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 do the data in the secrets is in sync with the data in the keycloak provision
If a slice or client is deleted clean up the resources in Keycloak, delete the secret from the users namespace and make the capacity available to another user.
If there is no slices for a particular Keycloak SharedService then the instance should be scaled down until a slice is asked for
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
3. provision this operator from the OLM https://github.com/operator-framework/operator-lifecycle-manager |
|
