We continue discussing the keycloak deployment on Kubernetes.

Keycloak does not need to be in a standalone mode. It could be a cloud service. Both are facilitated by the architecture of the Kubernetes service broker. The requirements partly come from the type of Identity provider serviced by the application using the Kubernetes cluster. In the case when Keycloak is installed and run on the same cluster as the application, the server connection does not need to be hardened in the service broker representation within the service catalog.
Recommendation: we reserve the ClusterServiceBroker, ClusterServiceClass, ClusterServicePlan as singleton representations for the Keycloak service broker. Even the ServiceInstance and ServiceBinding could be singleton instance specific to the Keycloak service broker. This way there is only one secret that the Service catalog controller creates which can then be mounted into the Pods. This secret will store only the connection details and credentials for the Keycloak service broker. All registrations for clients and roles will be maintained in the same generic K8s resource reserved for use with the service broker. Although this is not urgent for Beta release, it will bring consistency going forward.

The open service broker API recognized that setting up capabilities within the cluster will be rather limiting. On the other hand provisioning it in the cloud will immensely help scalability. Therefore the OSBA API could become the gateway to the cloud for the Applications deployed on the cluster.