Prevent usage of Keycloak /admin on provided KeyCloaks

Camunda 8 Topics
1

Hi,
we have a global Keycloak that we want to use for Camunda in our environment. On the helm charts to add a existing keycloak it is defined that we need to pass the admin account and password for it. We don´t want it as it creates a security risk if a 3rd party application has change access to our global keycloak.
Is there a way to remove this restrictions ?
Thanks
Robert

2

We also have a infrastructural problem with that. Camunda is connected from the outside to keycloak. But on the outside keycloak admin logon is disabled. Resulting the identity Container stopping with i.c.i.i.k.config.KeycloakConfiguration : HTTP 404 Not Found

3

Try enabling OIDC so that you don’t need admin credentials. There are two parts

  1. On the KeyCloak, setup OIDC.
  2. Configure Camunda OIDC Setup and select the type as generic.
4

Hi @tirolat - I think the admin user is only needed if you haven’t configured a realm yourself. Have a look at the docs below. If you follow the first one and provide a client secret to identity, I think you can skip the admin user. If you want Identity to configure Keycloak for you, then you need the admin user. (I haven’t tried this myself, so curious to hear your results if you try it!)

As for the URL, Identity needs access to Keycloak, so you can’t block Identity from calling Keycloak. There is a note about URL access in the first doc below, also:

As of the 8.5.3 release, Identity uses the Keycloak frontend URL instead of the backend URL. This change may affect you if you have blocked the Keycloak frontend URL from other services (including Camunda applications), and can potentially impact Identity’s functionality.

5

Unfortunately this is not true. I restored the admin user to “” but then i get the following error on Helm Deploy.
##[error]Error: INSTALLATION FAILED: execution error at (camunda-platform/charts/camunda-platform/templates/identity/deployment.yaml:172:24):
##[error][identity] To configure Keycloak, you have 3 options:
##[error] - Case 1: If you want to deploy Keycloak chart as it is, then set the following:
##[error] - keycloak.enabled: true
##[error] - Case 2: If you want to customize the Keycloak chart URL, then set the following:
##[error] - keycloak.enabled: true
##[error] - global.identity.keycloak.url.protocol
##[error] - global.identity.keycloak.url.host
##[error] - global.identity.keycloak.url.port
##[error] - Case 3: If you want to use already existing Keycloak, then set the following:
##[error] - keycloak.enabled: false
##[error] - global.identity.keycloak.url.protocol
##[error] - global.identity.keycloak.url.host
##[error] - global.identity.keycloak.url.port
##[error] - global.identity.keycloak.auth.adminUser
##[error] - global.identity.keycloak.auth.existingSecret
##[error]For more details, please check Camunda Helm chart documentation.

To use a own Keycloak is only Case 3. So the admin user access is needed for the deployment.
And the KeyCloak Url is available. we simply block /admin so nobody from outside has the possibility to make changes.

6

I´m not sure how the identity Provider creation would help here. We are talking about Keycloak basics and you can use camunda without the addition of identity providers.

7

Maybe as additional info. The Keycloak Binding to Camunda works. We did some url rewriting and could work around the problem with the external admin access. But still security wise i cannot see how we bring that out of POC Status to our main systems.

8

@tirolat - thanks for the info; I’ll take this to the Identity team and get some feedback!