Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update outdated keycloak container upstream #113

Open
jmontleon opened this issue Mar 21, 2023 · 5 comments
Open

Update outdated keycloak container upstream #113

jmontleon opened this issue Mar 21, 2023 · 5 comments

Comments

@jmontleon
Copy link
Member

jmontleon commented Mar 21, 2023

We're currently using keycloak 18.0.2-legacy. This image hasn't been updated in 9 months. It looks like the last legacy version was 19.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.

@rromannissen
Copy link
Contributor

@jmontleon is this still a valid concern now that Keycloak is no longer deployed/managed by the Konveyor operator?

@sjd78
Copy link
Member

sjd78 commented Feb 16, 2024

@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.

@sjd78
Copy link
Member

sjd78 commented Feb 16, 2024

Some extra info...

@sjd78
Copy link
Member

sjd78 commented Feb 16, 2024

cc: @ibolton336 , @dymurray

@shawn-hurley
Copy link
Contributor

I think that we need to add a discussion about this to the community call.

Things that I think we need to consider:

  1. We don't want to work without some authorization system. It will be hard for users to use the project if they can't protect it with at least authorization.
  2. We currently (AFAIK) hard code and set up a Realm in the hub. I wonder if there is a way to do this so that users can set up the RBAC in other systems to be used.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants