Identity still tries to create the dev-camunda-platform realm instead of using our external realm (dev-camunda-platform)

Camunda 8 Topics
1

Hi team,

We are deploying Camunda 8.8 (Helm chart 13.0.0) in self-managed mode with an external Keycloak.

Our goal is to use an existing realm (dev-camunda-platform) instead of letting Camunda Identity create its own camunda-platform realm.
We’ve followed the official documentation for connecting Identity to an external Keycloak instance and set the following environment variables (from our Helm ConfigMap):

CAMUNDA_IDENTITY_ISSUER_URL: "https://keycloak.gu.io/realms/dev-camunda-platform"
KEYCLOAK_REALM: "dev-camunda-platform"

However, when the Identity pod starts, it still attempts to create a new realm named camunda-platform, even though we expect it to use the existing one.
As a result, we get the following error in the logs:

Conflict detected. See logs for details

This clearly indicates that Identity is trying to create a realm that already exists.

Our expectation is that Identity should simply connect to and use the specified existing realm (dev-camunda-platform), not recreate it.

Here’s the relevant part of our ConfigMap:

IDENTITY_DATABASE_HOST: gu.rds.amazonaws.com
IDENTITY_DATABASE_NAME: keycloak
IDENTITY_DATABASE_USERNAME: keycloak
CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
CAMUNDA_IDENTITY_ISSUER_URL: 'https://keycloak.gu.io/realms/dop-camunda-platform'
CAMUNDA_MODELER_CLUSTERS_0_AUTHENTICATION: BEARER_TOKEN
CAMUNDA_MODELER_CLUSTERS_0_ID: default-cluster
CAMUNDA_MODELER_CLUSTERS_0_NAME: DOP DEV Camunda 8.8.0
CAMUNDA_MODELER_CLUSTERS_0_OAUTH_SCOPE: 'openid email profile'
CAMUNDA_MODELER_CLUSTERS_0_OAUTH_URL: 'https://keycloak.gu.io/realms/dop-camunda-platform/protocol/openid-connect/token'
CAMUNDA_MODELER_CLUSTERS_0_URL_GRPC: "grpcs://zeebe.camunda.dop.geekup.io:443"
CAMUNDA_MODELER_CLUSTERS_0_URL_REST: "https://camunda.dop.geekup.io"
CAMUNDA_MODELER_CLUSTERS_0_VERSION: 8.8.0
CAMUNDA_MODELER_INTERNAL_API: 'http://camunda-web-modeler-restapi:80'
CAMUNDA_MODELER_LOG_LEVEL: DEBUG
LOGGING_LEVEL_IO_CAMUNDA_MODELER: DEBUG
LOGGING_LEVEL_IO_GRPC: DEBUG
LOG_LEVEL_CLIENT: DEBUG
LOG_LEVEL_WEBAPP: DEBUG
WEB_MODELER_REST_API_EXTERNAL_DATABASE_URL: jdbc:postgresql://gu.rds.amazonaws.com:5432/modeler-db
WEB_MODELER_REST_API_EXTERNAL_DATABASE_USERNAME: modeler
WEB_MODELER_REST_API_EXTERNAL_SMTP_FROM_ADDRESS: no-reply@example.com
WEB_MODELER_REST_API_EXTERNAL_SMTP_HOST: smtp.example.com
WEB_MODELER_REST_API_EXTERNAL_SMTP_USER: user

We’ve verified that:

  • The external Keycloak is reachable and operational.

  • The realm dev-camunda-platform already exists.

  • The client_id values match what we configured in Keycloak.

:backhand_index_pointing_right: Question:
How can we completely disable the automatic realm creation by Camunda Identity and force it to use our external realm instead?

We’re following this topic for context:
https://forum.camunda.io/t/how-to-disable-automatic-creation-of-the-camunda-platform-realm-in-camunda-identity-and-force-usage-of-external-realm-qportal/63229/5

Thanks in advance for clarifying whether this behavior can be disabled or if Identity currently always tries to bootstrap the default realm on startup.

2

Hi @Geek_Up_Linh,

Thank you for the detailed question about configuring Camunda Identity with an external Keycloak realm.

Unfortunately, there is currently no officially supported way to completely disable the automatic realm creation/bootstrap behavior in Camunda Identity. This is a known limitation that you’ve correctly identified.

Current Behavior

Even when you properly configure Identity to use an external realm with:

  • KEYCLOAK_REALM: "dev-camunda-platform"
  • CAMUNDA_IDENTITY_ISSUER_URL: "https://keycloak.gu.io/realms/dev-camunda-platform"

Identity will still attempt to create/bootstrap resources in the specified realm during startup, which causes the “Conflict detected” error you’re seeing when those resources already exist.

Configuration Check

I notice a small discrepancy in your configuration. In your ConfigMap, you have:

CAMUNDA_IDENTITY_ISSUER_URL: 'https://keycloak.gu.io/realms/dop-camunda-platform'

But you mentioned wanting to use the dev-camunda-platform realm. Make sure the realm name in the issuer URL matches your KEYCLOAK_REALM setting.

Current Limitations

Based on the official documentation and community discussions:

  1. No disable flag exists: Variables like IDENTITY_KEYCLOAK_CREATE_REALM=false are not recognized by Identity
  2. Bootstrap logic is hard-coded: The realm and client creation logic appears to be built into Identity’s startup process
  3. Workarounds are limited: There’s no documented way to bypass this behavior in Camunda 8.8

Recommendations

Since this is a known limitation without a current workaround:

  1. Contact Camunda Support: If this is critical for your deployment, I recommend reaching out to Camunda support directly for guidance
  2. Monitor for updates: Keep an eye on future Camunda releases for potential improvements to this behavior
  3. Consider filing a feature request: You could submit this as a feature request on the Camunda roadmap if it doesn’t already exist

References

I understand this isn’t the answer you were hoping for, but this appears to be a current product limitation rather than a configuration issue on your end.

Would you like me to help you explore any alternative approaches or assist with filing a feature request?

3

Hi team,

Thank you for the clarification.

I’ve double-checked my configuration, and the realm setup is indeed correct. Here’s the relevant part of my ConfigMap for reference:

IDENTITY_DATABASE_HOST: gu.rds.amazonaws.com
IDENTITY_DATABASE_NAME: keycloak
IDENTITY_DATABASE_USERNAME: keycloak

KEYCLOAK_REALM: "dev-camunda-platform"
CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
CAMUNDA_IDENTITY_ISSUER_URL: "https://keycloak.gu.io/realms/dev-camunda-platform"

CAMUNDA_MODELER_CLUSTERS_0_AUTHENTICATION: BEARER_TOKEN
CAMUNDA_MODELER_CLUSTERS_0_ID: default-cluster
CAMUNDA_MODELER_CLUSTERS_0_NAME: DOP DEV Camunda 8.8.0
CAMUNDA_MODELER_CLUSTERS_0_OAUTH_SCOPE: "openid email profile"
CAMUNDA_MODELER_CLUSTERS_0_OAUTH_URL: "https://keycloak.gu.io/realms/dev-camunda-platform/protocol/openid-connect/token"
CAMUNDA_MODELER_CLUSTERS_0_URL_GRPC: "grpcs://zeebe.camunda.dop.geekup.io:443"
CAMUNDA_MODELER_CLUSTERS_0_URL_REST: "https://camunda.dop.geekup.io"
CAMUNDA_MODELER_CLUSTERS_0_VERSION: 8.8.0
CAMUNDA_MODELER_INTERNAL_API: "http://camunda-web-modeler-restapi:80"

WEB_MODELER_REST_API_EXTERNAL_DATABASE_URL: jdbc:postgresql://gu.rds.amazonaws.com:5432/modeler-db
WEB_MODELER_REST_API_EXTERNAL_DATABASE_USERNAME: modeler
WEB_MODELER_REST_API_EXTERNAL_SMTP_FROM_ADDRESS: no-reply@example.com
WEB_MODELER_REST_API_EXTERNAL_SMTP_HOST: smtp.example.com
WEB_MODELER_REST_API_EXTERNAL_SMTP_USER: user

So the CAMUNDA_IDENTITY_ISSUER_URL and KEYCLOAK_REALM values are both pointing to the same realm (dev-camunda-platform).

Despite this correct setup, Identity still attempts to bootstrap the realm and clients during startup, which leads to a “Conflict detected” error because those resources already exist in Keycloak.

It seems this aligns with the limitation you mentioned — that there’s currently no supported flag (like IDENTITY_KEYCLOAK_CREATE_REALM=false) to disable realm bootstrapping when connecting to an external Keycloak.

I’ll keep monitoring future releases for potential improvements or configuration options to disable this behavior.
If needed, I can help file a feature request to track this more officially.

Thanks again for the clarification and your time!

4

Summary

The issue you’re experiencing is a known limitation in Camunda Identity 8.8. Here are the key points:

The Problem

  • Camunda Identity always attempts to bootstrap/create realm resources during startup, even when configured to use an external Keycloak realm
  • This causes “Conflict detected” errors when those resources already exist in your external Keycloak
  • Your configuration with KEYCLOAK_REALM: "dev-camunda-platform" and matching CAMUNDA_IDENTITY_ISSUER_URL is correct

Current Status

  • No supported workaround exists to disable the automatic realm creation behavior
  • Variables like IDENTITY_KEYCLOAK_CREATE_REALM=false are not recognized by Identity
  • The bootstrap logic appears to be hard-coded in Identity’s startup process

Next Steps

Since this is a product limitation rather than a configuration issue:

  1. Monitor future releases for improvements to this behavior
  2. Contact Camunda Support if this is blocking your deployment
  3. Consider filing a feature request on the Camunda roadmap if one doesn’t already exist

References

Your configuration is correct - this is simply a current limitation of the product that the Camunda team may address in future releases.