Open jmontleon opened 1 year ago
@jmontleon is this still a valid concern now that Keycloak is no longer deployed/managed by the Konveyor operator?
@jmontleon is this still a valid concern now that Keycloak is no longer deployed/managed by the Konveyor operator?
While researching for #166, and looking through the operator's main ansible task, the operator still very much controls a keycloak deployment when auth is enabled. Different permutations of the feature_auth_type
and app_profile
variables, cause auth can be deployed in different ways. With auth enabled, the operator will manage a keycloak deployment or a RHSSO custom resource.
Under the default auth enabled upstream circumstances, a keycloak container is deployed:
If the app_profile is set to "mta", a RHSSO CR is deployed:
IMHO, the app_profile konveyor keycloak version and the app_profile mta RHSSO reference should try to match up as best we can so the hub and ui sso functions have the best chance of working in both deployment configurations.
Some extra info...
cc: @ibolton336 , @dymurray
I think that we need to add a discussion about this to the community call.
Things that I think we need to consider:
I think that upstream, we should endeavor to work with popular tools like https://auth0.com and delegate to a k8s cluster if they have that set up already.
We're currently using keycloak
18.0.2-legacy
. This image hasn't been updated in 9 months. It looks like the lastlegacy
version was19.0.3
which was only update 5 months ago.If we need to do something so we can get on a current non-legacy release we should do it so we're not using outdated and potentially vulnerable releases of keycloak.