Error 404. No static resource auth/realms/camunda-platform/protocol/openid-connect/auth.

Camunda 8 Topics Discussion & Questions
1

Hello. A noob here.

I’ve installed a self-managed 8.7 in EKS for POC and training purposes just with the default components, no ingress, no DNS. I did the port-forwarding for ports 8080 and 18080 and managed to add the Test M2M application as instructed in the page: Install Camunda 8 on an EKS cluster | Camunda 8 Docs

After minutes, the page became irresponsive and now I’m not getting the login page again, localhost:8080 redirects to http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/auth?client_id=camunda-identity&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Flogin-callback&response_type=code&scope=openid+email&state=&audience=camunda-identity-resource-server

and I’m seeing the error:

{"type":"about:blank","title":"Not Found","status":404,"detail":"No static resource auth/realms/camunda-platform/protocol/openid-connect/auth.","instance":"/auth/realms/camunda-platform/protocol/openid-connect/auth"}

How could I troubleshoot this issue?

I had to upgrade my EKS Cluster to version 1.33 replacing the OS of the nodes because of end of support in AWS, the problem existed before the upgrade and remains the same after the successful update of the cluster.

I’m thinking that Console and Web Modeler are needed for my POC and as I’m not seeing a simple way to enable them, I feel uninstalling Camunda and doing everything again sounds like an option.

What would you think should be the easiest and faster way to have the login page again?

And to enable Web Modeler and Console?

I know I’m mixing two topics here, sorry for that…

Kind regards.

2

Hello @fmontellano! Welcome to the Camunda community! :waving_hand:

I can help you troubleshoot both issues you’re facing. Let me address them one by one:

Issue 1: 404 Error with Authentication

The 404 error "No static resource auth/realms/camunda-platform/protocol/openid-connect/auth" typically indicates a problem with your Keycloak/Identity configuration. Here are the most likely causes and solutions:

1. Check if the Camunda Platform Realm Exists

The most common cause is that the camunda-platform realm wasn’t created in Keycloak. You can verify this by:

# Port-forward to Keycloak (usually port 18080)
kubectl port-forward svc/camunda-keycloak 18080:80

# Check if the realm exists
curl -kv http://localhost:18080/auth/realms/camunda-platform

If you get a 404, the realm is missing and needs to be created.

2. Verify Keycloak Pod Status

Check if Keycloak and Identity pods are running properly:

kubectl get pods -n <your-namespace>
kubectl logs <keycloak-pod-name>
kubectl logs <identity-pod-name>

3. Restart Identity Service

Sometimes Identity starts before Keycloak is fully ready. Try restarting the Identity pod:

kubectl delete pod <identity-pod-name>

4. Check URL Consistency

Ensure all authentication URLs are consistent. Since you’re using port-forwarding, make sure your configuration uses http://localhost:18080 for Keycloak URLs.

Issue 2: Enabling Web Modeler and Console

To enable Web Modeler and Console in your Camunda 8.7 self-managed deployment, you need to update your Helm values. Create or update your values.yaml file:

webModeler:
  enabled: true
  restapi:
    mail:
      # Required for Web Modeler notifications
      smtpHost: smtp.example.com  # Replace with your SMTP server
      smtpPort: 587
      smtpUser: user              # Replace with your SMTP user
      smtpPassword: secret        # Replace with your SMTP password
      fromAddress: no-reply@example.com

postgresql:
  enabled: true  # Enables PostgreSQL for Web Modeler

console:
  enabled: true

Then upgrade your Helm deployment:

helm upgrade camunda camunda/camunda-platform --version 8.7.x -n <namespace> --values values.yaml

Recommended Approach

Given your situation, I’d suggest this order of operations:

  1. First, fix the authentication issue by checking the Keycloak realm and restarting Identity if needed
  2. Once authentication works, upgrade your Helm deployment to enable Web Modeler and Console
  3. Avoid a complete reinstall unless the troubleshooting steps don’t resolve the authentication issue

Additional Troubleshooting

If the above doesn’t resolve the authentication issue, please share:

  • Keycloak pod logs: kubectl logs <keycloak-pod-name>
  • Identity pod logs: kubectl logs <identity-pod-name>
  • Your current Helm values (with sensitive data redacted)

References:

Let me know how these steps work for you, and feel free to share the logs if you need further assistance!

3

Thanks, curl is returning 404 indeed…

$ curl -kv http://localhost:18080/auth/realms/camunda-platform

  • Host localhost:18080 was resolved.

  • IPv6: ::1

  • IPv4: 127.0.0.1

  • Trying [::1]:18080…

  • Connected to localhost (::1) port 18080

  • using HTTP/1.x

GET /auth/realms/camunda-platform HTTP/1.1Host: localhost:18080User-Agent: curl/8.15.0Accept: /

  • Request completely sent off< HTTP/1.1 404< Vary: Origin< Vary: Access-Control-Request-Method< Vary: Access-Control-Request-Headers< X-Content-Type-Options: nosniff< X-XSS-Protection: 0< Cache-Control: no-cache, no-store, max-age=0, must-revalidate< Pragma: no-cache< Expires: 0< X-Frame-Options: DENY< Content-Type: application/problem+json;charset=UTF-8< Transfer-Encoding: chunked< Date: Thu, 02 Oct 2025 19:01:06 GMT<{“type”:“about:blank”,“title”:“Not Found”,“status”:404,“detail”:“No static resource auth/realms/camunda-platform.”,“instance”:“/auth/realms/camunda-platform”}* Connection #0 to host localhost left intact

However, if I try to create the realm manually (deleting and restarting the pod camunda-identity is not helping) I get 404 as well:

{"type":"about:blank","title":"Not Found","status":404,"detail":"No static resource auth/admin.","instance":"/auth/admin"}
4

Thanks for confirming! The 404 on both /auth/realms/camunda-platform and /auth/admin indicates that Keycloak is running but the camunda-platform realm was never created. This is a common issue in self-managed deployments.

Let’s troubleshoot this step by step:

1. Check Keycloak and Identity Pod Status

First, let’s see what’s happening with your pods:

# Check all pods in your namespace
kubectl get pods -n <your-namespace>

# Check Keycloak logs
kubectl logs <keycloak-pod-name> -n <your-namespace>

# Check Identity logs  
kubectl logs <identity-pod-name> -n <your-namespace>

Look for any errors during startup, especially around realm creation.

2. Verify Keycloak is Accessible

Try accessing the Keycloak admin console directly:

# Port-forward to Keycloak
kubectl port-forward svc/camunda-keycloak 18080:80 -n <your-namespace>

# Try accessing the admin console
curl -kv http://localhost:18080/auth/admin/master/console/

If this also returns 404, there might be a deeper Keycloak configuration issue.

3. Check Your Helm Values

The realm creation might have failed due to configuration issues. Can you share your current Helm values file (with sensitive data redacted)? Specifically, I need to see:

  • How Keycloak is configured
  • Any custom ingress or TLS settings
  • Identity configuration

4. Manual Realm Creation (Temporary Fix)

If Keycloak admin is accessible, you can manually create the realm as a temporary fix:

  1. Access Keycloak admin console at http://localhost:18080/auth/admin/
  2. Login with admin credentials (check your Helm values or secrets)
  3. Create a new realm called camunda-platform
  4. Import the Camunda realm configuration

5. Recommended Solution: Helm Upgrade

The most reliable fix is to upgrade your Helm deployment with proper configuration. Based on common issues, try this approach:

# First, get your current values
helm get values camunda -n <your-namespace> > current-values.yaml

# Create a new values file with explicit Keycloak configuration
cat > fixed-values.yaml << EOF
global:
  identity:
    keycloak:
      url:
        protocol: "http"
        host: "camunda-keycloak"
        port: "80"

identityKeycloak:
  enabled: true
  postgresql:
    enabled: true

# Add Web Modeler and Console while we're at it
webModeler:
  enabled: true
  restapi:
    mail:
      smtpHost: smtp.example.com  # Replace with your SMTP
      smtpPort: 587
      smtpUser: user
      smtpPassword: secret
      fromAddress: no-reply@example.com

postgresql:
  enabled: true

console:
  enabled: true
EOF

# Upgrade the deployment
helm upgrade camunda camunda/camunda-platform --version 8.7.x -n <your-namespace> --values fixed-values.yaml

6. Post-Upgrade Steps

After the upgrade:

  1. Wait for all pods to be ready
  2. Check if the realm was created: curl -kv http://localhost:18080/auth/realms/camunda-platform
  3. If the realm exists, restart the Identity pod to ensure it connects properly
  4. Test the login page at http://localhost:8080

Questions for You:

  1. What does kubectl get pods show for Keycloak and Identity pods?
  2. Are there any errors in the Keycloak logs?
  3. Did you use any custom Helm values during the initial installation?
  4. Are you using any ingress or TLS configuration?

Please share the pod logs and your current Helm configuration (redacted), and I’ll help you get this resolved! :wrench:

5

Currently I’m not using the internal postgresql setting, my current-values.yaml shows:

identity:
externalDatabase:
database: camunda_identity
enabled: true
existingSecret: identity-postgres-secret
existingSecretPasswordKey: password
host: ``camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com
port: 5432
username: identity_db
fullURL: ``http://localhost:8080

Am I correct assuming I don’t need to enable postgresql now?

6

You’re absolutely correct! Since you’re using an external PostgreSQL database (AWS RDS Aurora) for Identity, you don’t need to enable the internal PostgreSQL for Identity. However, there are a few important points to clarify:

Database Configuration Clarification

  1. Identity Database: You’re correctly using external RDS :white_check_mark:
  2. Web Modeler Database: Web Modeler needs its own database. You have two options:
    • Use the internal PostgreSQL (postgresql.enabled: true) - Recommended for POC
    • Configure Web Modeler to use your external RDS (more complex)

Corrected Values Configuration

Here’s the corrected values.yaml for your setup:

# Keep your existing Identity external database config
identity:
  externalDatabase:
    database: camunda_identity
    enabled: true
    existingSecret: identity-postgres-secret
    existingSecretPasswordKey: password
    host: camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com
    port: 5432
    username: identity_db

# Keycloak configuration (explicit)
global:
  identity:
    keycloak:
      url:
        protocol: "http"
        host: "camunda-keycloak"
        port: "80"

identityKeycloak:
  enabled: true
  # Keycloak will use its own internal database for this POC

# Enable Web Modeler with internal PostgreSQL (simplest for POC)
webModeler:
  enabled: true
  restapi:
    mail:
      smtpHost: smtp.example.com  # Replace with your SMTP server
      smtpPort: 587
      smtpUser: user              # Replace with your SMTP credentials
      smtpPassword: secret
      fromAddress: no-reply@example.com

# Enable PostgreSQL ONLY for Web Modeler (not Identity)
postgresql:
  enabled: true

# Enable Console
console:
  enabled: true

Alternative: Use External RDS for Web Modeler Too

If you prefer to use your RDS for Web Modeler as well (more complex but cleaner):

# Your existing Identity config...
identity:
  externalDatabase:
    # ... your existing config

# Web Modeler with external database
webModeler:
  enabled: true
  restapi:
    externalDatabase:
      enabled: true
      host: camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com
      port: 5432
      database: camunda_webmodeler  # Create this database in your RDS
      username: webmodeler_db       # Create this user in your RDS
      existingSecret: webmodeler-postgres-secret
      existingSecretPasswordKey: password
    mail:
      # ... your SMTP config

# Disable internal PostgreSQL since you're using external
postgresql:
  enabled: false

console:
  enabled: true

Next Steps

  1. For POC purposes, I recommend the first approach (internal PostgreSQL for Web Modeler)

  2. Apply the configuration:

    helm upgrade camunda camunda/camunda-platform --version 8.7.x -n <your-namespace> --values values.yaml

  3. Monitor the deployment:

    kubectl get pods -n <your-namespace> -w

  4. Check if the realm gets created after the upgrade:

    curl -kv http://localhost:18080/auth/realms/camunda-platform

Still Need Those Logs

While we’re updating the configuration, can you still share:

kubectl logs <keycloak-pod-name> -n <your-namespace>
kubectl logs <identity-pod-name> -n <your-namespace>

This will help us understand why the realm wasn’t created initially.

Which approach would you like to take for Web Modeler’s database? :thinking:

7

For context and clarity, the realm was created initially, I managed to login to the Identity app at http://localhost:8080 and I was able to create an application named Test of type M2M. Few minutes after that either I did lost connection or I did press logout and then was not possible to access Identity anymore.

Logs are showing nothing evidently wrong, the message about the license doesn’t seem relevant here. For Identity:

PS C:\Users\FMONTELLANO> kubectl logs camunda-identity-5c4459478f-q5k8p --namespace camunda --follow

.   ____          _            __ _ _/\ / ’ __ _ () __  __ _ \ \ \ ( ( )__ | '_ | '| | ’ / ` | \ \ \ \/  )| |)| | | | | || (| |  ) ) ) )’  || .__|| ||| |_, | / / / /=========||==============|/=////

:: Spring Boot ::               (v3.3.13)

2025-10-02 18:53:39.716  INFO 1 — [           main] i.c.i.Application                        : Starting Application using Java 17.0.16 with PID 1 (/app/identity.jar started by camunda in /app)2025-10-02 18:53:39.725  INFO 1 — [           main] i.c.i.Application                        : The following 1 profile is active: “keycloak”2025-10-02 18:53:41.724  WARN 1 — [           main] trationDelegate$BeanPostProcessorChecker : Bean ‘globalMethodSecurityConfig’ of type [io.camunda.identity.security.config.GlobalMethodSecurityConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [healthEndpointGroupsBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.2025-10-02 18:53:42.654  WARN 1 — [           main] i.c.i.c.AppConfig                        : Expected a valid license but encountered an invalid one instead. Please check the license key and try again.2025-10-02 18:53:44.314  INFO 1 — [           main] i.c.i.Application                        : Started Application in 5.869 seconds (process running for 7.327)

And for Keycloack:

PS C:\Users\FMONTELLANO> kubectl logs camunda-identity-5c4459478f-q5k8p --namespace camunda --follow

.   ____          _            __ _ _/\ / ’ __ _ () __  __ _ \ \ \ ( ( )__ | '_ | '| | ’ / ` | \ \ \ \/  )| |)| | | | | || (| |  ) ) ) )’  || .__|| ||| |_, | / / / /=========||==============|/=////

:: Spring Boot ::               (v3.3.13)

2025-10-02 18:53:39.716  INFO 1 — [           main] i.c.i.Application                        : Starting Application using Java 17.0.16 with PID 1 (/app/identity.jar started by camunda in /app)2025-10-02 18:53:39.725  INFO 1 — [           main] i.c.i.Application                        : The following 1 profile is active: “keycloak”2025-10-02 18:53:41.724  WARN 1 — [           main] trationDelegate$BeanPostProcessorChecker : Bean ‘globalMethodSecurityConfig’ of type [io.camunda.identity.security.config.GlobalMethodSecurityConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [healthEndpointGroupsBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.2025-10-02 18:53:42.654  WARN 1 — [           main] i.c.i.c.AppConfig                        : Expected a valid license but encountered an invalid one instead. Please check the license key and try again.2025-10-02 18:53:44.314  INFO 1 — [           main] i.c.i.Application                        : Started Application in 5.869 seconds (process running for 7.327)PS C:\Users\FMONTELLANO> kubectl logs camunda-keycloak-0 --namespace camunda --followDefaulted container “keycloak” out of: keycloak, prepare-write-dirs (init)keycloak 18:49:04.59 INFO  ==>keycloak 18:49:04.59 INFO  ==> Welcome to the Bitnami keycloak containerkeycloak 18:49:04.59 INFO  ==> Subscribe to project updates by watching keycloak 18:49:04.59 INFO  ==> NOTICE: Starting August 28th, 2025, only a limited subset of images/charts will remain available for free. Backup will be available for some time at the ‘Bitnami Legacy’ repository. More info at keycloak 18:49:04.59 INFO  ==>keycloak 18:49:04.60 INFO  ==> ** Starting keycloak setup **keycloak 18:49:04.60 INFO  ==> Validating settings in KEYCLOAK_* env vars…keycloak 18:49:04.61 INFO  ==> Trying to connect to PostgreSQL server camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com…keycloak 18:49:04.63 INFO  ==> Found PostgreSQL server listening at camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com:5432keycloak 18:49:04.63 INFO  ==> Configuring database settingskeycloak 18:49:04.65 INFO  ==> Enabling statisticskeycloak 18:49:04.65 INFO  ==> Enabling health endpointskeycloak 18:49:04.66 INFO  ==> Configuring http settingskeycloak 18:49:04.67 INFO  ==> Configuring hostname settingskeycloak 18:49:04.67 INFO  ==> Configuring cache countkeycloak 18:49:04.68 INFO  ==> Configuring log levelkeycloak 18:49:04.68 INFO  ==> Configuring proxykeycloak 18:49:04.69 INFO  ==> ** keycloak setup finished! **

keycloak 18:49:04.69 INFO  ==> ** Starting keycloak **Appending additional Java properties to JAVA_OPTSWARNING: The following used options or option values are DEPRECATED and will be removed or their behaviour changed in a future release:- cache-stack=kubernetes: Use ‘jdbc-ping’ instead by leaving it unset.Consult the Release Notes for details.Updating the configuration and installing your custom providers, if any. Please wait.2025-10-02 18:49:09,161 WARN  [org.keycloak.services] (build-3) KC-SERVICES0047: metrics (org.jboss.aerogear.keycloak.metrics.MetricsEndpointFactory) is implementing the internal SPI realm-restapi-extension. This SPI is internal and may change without notice2025-10-02 18:49:09,849 WARN  [org.keycloak.services] (build-3) KC-SERVICES0047: metrics-listener (org.jboss.aerogear.keycloak.metrics.MetricsEventListenerFactory) is implementing the internal SPI eventsListener. This SPI is internal and may change without notice2025-10-02 18:49:16,044 INFO  [io.quarkus.deployment.QuarkusAugmentor] (main) Quarkus augmentation completed in 9396msWARNING: The following used options or option values are DEPRECATED and will be removed or their behaviour changed in a future release:- cache-stack=kubernetes: Use ‘jdbc-ping’ instead by leaving it unset.Consult the Release Notes for details.Running the server in development mode. DO NOT use this configuration in production.2025-10-02 18:49:21,097 INFO  [org.keycloak.spi.infinispan.impl.embedded.JGroupsConfigurator] (main) JGroups Encryption enabled (mTLS).2025-10-02 18:49:21,329 INFO  [org.keycloak.jgroups.certificates.CertificateReloadManager] (main) Starting JGroups certificate reload manager2025-10-02 18:49:21,408 INFO  [org.infinispan.CONTAINER] (main) ISPN000556: Starting user marshaller ‘org.infinispan.commons.marshall.ImmutableProtoStreamMarshaller’2025-10-02 18:49:21,588 INFO  [org.infinispan.CLUSTER] (main) ISPN000078: Starting JGroups channel ISPN with stack kubernetes2025-10-02 18:49:21,589 INFO  [org.jgroups.JChannel] (main) local_addr: 6d4bb6bd-3f71-4df6-9afe-f267acea77fc, name: camunda-keycloak-0-12332025-10-02 18:49:21,598 INFO  [org.jgroups.protocols.FD_SOCK2] (main) server listening on *:578002025-10-02 18:49:23,601 INFO  [org.jgroups.protocols.pbcast.GMS] (main) camunda-keycloak-0-1233: no members discovered after 2002 ms: creating cluster as coordinator2025-10-02 18:49:23,618 INFO  [org.infinispan.CLUSTER] (main) ISPN000094: Received new cluster view for channel ISPN: [camunda-keycloak-0-1233|0] (1) [camunda-keycloak-0-1233]2025-10-02 18:49:23,619 INFO  [org.keycloak.jgroups.certificates.CertificateReloadManager] (main) Reloading JGroups Certificate2025-10-02 18:49:23,662 INFO  [org.infinispan.CLUSTER] (main) ISPN000079: Channel ISPN local address is camunda-keycloak-0-1233, physical addresses are [10.192.13.236:7800]2025-10-02 18:49:23,953 INFO  [org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory] (main) Node name: camunda-keycloak-0-1233, Site name: null2025-10-02 18:49:24,942 INFO  [io.quarkus] (main) Keycloak 26.3.2 on JVM (powered by Quarkus 3.20.2) started in 8.768s. Listening on: http://0.0.0.0:80802025-10-02 18:49:24,943 INFO  [io.quarkus] (main) Profile dev activated.2025-10-02 18:49:24,943 INFO  [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-postgresql, keycloak, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, vertx]

I’ll go with the simple one, internal PostgreSQL, will prepare the upgrade and let you know…

8

Ah, this is very helpful context! :bullseye: The fact that you initially could log in and create the M2M application, but then lost access, suggests a different issue than I initially thought.

Root Cause Analysis

Since it worked initially but then stopped, this points to one of these scenarios:

  1. Keycloak realm persistence issue - The realm was created but not properly persisted to the database
  2. Session/token expiration combined with a configuration drift
  3. Database connection issue between Keycloak and your RDS

Looking at your logs, I notice Keycloak is connecting to your RDS Aurora instance:

==> Found PostgreSQL server listening at camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com:5432

What to Watch During the Upgrade

When you run the Helm upgrade, monitor these key points:

  1. Keycloak startup sequence:

    kubectl logs camunda-keycloak-0 -n camunda --follow

    Look for realm creation messages.

  2. Identity connection to Keycloak:

    kubectl logs <identity-pod-name> -n camunda --follow

    Watch for successful Keycloak connection messages.

  3. Realm persistence check:
    After the upgrade, immediately check:

    curl -kv http://localhost:18080/auth/realms/camunda-platform

Recommended Upgrade Command

Based on your setup, here’s the exact command:

# Create upgrade-values.yaml
cat > upgrade-values.yaml << EOF
# Keep your existing Identity external database config
identity:
  externalDatabase:
    database: camunda_identity
    enabled: true
    existingSecret: identity-postgres-secret
    existingSecretPasswordKey: password
    host: camunda-aurora-pg-std.cluster-ctx0umbrqvly.sa-east-1.rds.amazonaws.com
    port: 5432
    username: identity_db

# Explicit Keycloak configuration
global:
  identity:
    keycloak:
      url:
        protocol: "http"
        host: "camunda-keycloak"
        port: "80"

identityKeycloak:
  enabled: true

# Web Modeler with internal PostgreSQL
webModeler:
  enabled: true
  restapi:
    mail:
      smtpHost: smtp.gmail.com  # Replace with your SMTP
      smtpPort: 587
      smtpUser: your-email@gmail.com
      smtpPassword: your-app-password
      fromAddress: your-email@gmail.com

postgresql:
  enabled: true

console:
  enabled: true
EOF

# Run the upgrade
helm upgrade camunda camunda/camunda-platform --version 8.7.x -n camunda --values upgrade-values.yaml

Post-Upgrade Verification Steps

  1. Wait for all pods to be ready:

    kubectl get pods -n camunda -w

  2. Check realm immediately:

    curl -kv http://localhost:18080/auth/realms/camunda-platform

  3. Test login:

    kubectl port-forward svc/camunda-identity 8080:80 -n camunda

    Then visit http://localhost:8080

  4. If realm exists but login fails, restart Identity:

    kubectl delete pod <identity-pod-name> -n camunda

Backup Plan

If the issue persists after upgrade, we can:

  1. Export the current Keycloak database state
  2. Manually recreate the realm with proper persistence settings
  3. Check RDS connection stability

Let me know how the upgrade goes! I’m particularly interested in whether the realm persists this time. :rocket:

9

I’m sorry, I’m not being able to perform the upgrade.

When I tried with the command exactly as you post it, I received an error about the repo cannot be found. So I’ve changed for something more likely the command I ran to install Camunda the first time.

helm upgrade camunda camunda-platform --repo ``https://helm.camunda.io`` --version 12.6.1 -n camunda --values fixed-values.yml

The error was:

Error: UPGRADE FAILED: execution error at (camunda-platform/charts/identityKeycloak/charts/postgresql/templates/secrets.yaml:26:16):PASSWORDS ERROR: You must provide your current passwords when upgrading the release.Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.Further information can be obtained at 

'global.postgresql.auth.password' must not be empty, please add '--set global.postgresql.auth.password=$PASSWORD' to the command. To get the current value:

    export PASSWORD=$(kubectl get secret --namespace "camunda" camunda-postgresql -o jsonpath="{.data.password}" | base64 -d)

I don’t have a secret named camunda-postgresql, I think the password is looking for is stored in identity-postgres-secret so I obtained the current value of data.password and tried again:

$ helm upgrade camunda camunda-platform --repo ``https://helm.camunda.io`` --version 12.6.1 -n camunda --values fixed-values.yml --set global.postgresql.auth.password=$PASSWORD
Error: UPGRADE FAILED: execution error at (camunda-platform/charts/identityKeycloak/templates/statefulset.yaml:37:29):
PASSWORDS ERROR: You must provide your current passwords when upgrading the release.
Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.
Further information can be obtained at 

'auth.adminPassword' must not be empty, please add '--set auth.adminPassword=$ADMIN_PASSWORD' to the command. To get the current value:

    export ADMIN_PASSWORD=$(kubectl get secret --namespace "camunda" camunda-keycloak -o jsonpath="{.data.admin-password}" | base64 -d)

Again, I don’t have the secret named camunda-keycloack and assuming the password is the one stored in my identity-keycloak-secret I adapted the export command and try one last time:

$ helm upgrade camunda camunda-platform --repo ``https://helm.camunda.io`` --version 12.6.1 -n camunda --values fixed-values.yml --set global.postgresql.auth.password=$PASSWORD --set auth.adminPassword=$ADMIN_PASSWORD
Error: UPGRADE FAILED: execution error at (camunda-platform/charts/identityKeycloak/templates/statefulset.yaml:37:29):
PASSWORDS ERROR: You must provide your current passwords when upgrading the release.
Note that even after reinstallation, old credentials may be needed as they may be kept in persistent volume claims.
Further information can be obtained at 

'auth.adminPassword' must not be empty, please add '--set auth.adminPassword=$ADMIN_PASSWORD' to the command. To get the current value:

    export ADMIN_PASSWORD=$(kubectl get secret --namespace "camunda" camunda-keycloak -o jsonpath="{.data.admin-password}" | base64 -d)

I’ve verified that $ADMIN_PASSWORD is actually filled with the proper value…

$ echo $ADMIN_PASSWORD
passw0rd%98