HTTP 401 Unathorized Unable to connect to Keycloack

[mkelton]

Hello,

please give me a hint about yaml configuration for Identity.
I installed Camunda with following config:

global:
  identity:
    auth:
      enabled: true

identityKeycloak:
  enabled: true
  realm: camunda-platform
  clientSecret: au8Ime1xgUuVOPCXLfKgnBiMj5JDbJSK
  url: http://camunda-platform-keycloak:80/auth
  auth:
    adminUser: "admin"
    existingSecretKey: "admin-password"
  image:
    repository: bitnami/keycloak
    tag: 25.0.6
  postgresql:
    image:
      repository: bitnami/postgresql
      tag: 17.0.0

optimize:
  enabled: false
zeebe:
  clusterSize: 1
  partitionCount: 1
  replicationFactor: 1
  pvcSize: 2Gi

zeebeGateway:
  replicas: 1

connectors:
  enabled: true
  inbound:
    mode: disabled
elasticsearch:
  master:
    replicaCount: 1
    persistence:
      size: 2Gi

And that installation was working fine. I just had to search for the admin password

kubectl exec -it camunda-platform-keycloak-0 -- /bin/sh , printenv | grep KEYCLOAK_ADMIN_PASSWORD'

I changed it in Keycloack, still good. But after host restart Identity module cannot connect to Keycloack; HTTP 401 Unathorized Unable to connect to Keycloack
So I guess Identity was using ‘KEYCLOAK_ADMIN_PASSWORD’ variable, right?
But why it was working after password change? Session?

Anyway, what should I put in yaml config as password and account?
In some example config I see:

  auth:
    existingSecret: "integration-test-credentials"
    passwordSecretKey: "identity-keycloak-admin-password"

Looks like same password stored in two different secrets, why?
I should create these secrets BEFORE I start installation, something like:

kubectl create secret generic camunda-keycloak-secret --from-literal=admin-password=mySecretPassword -n default
?
Thanks for your help

[nathan.loding]

Hi @mkelton - I suspect your guess about an existing session after the password change is correct. The secrets in the Helm charts do need to be created before a deployment. You should be able to create new secrets and do a new deployment to update those values. The two auth values you list do have a strange naming convention, and I’ve reached out to the platform developers for some more information on why that is, but it should be used like any other Kubernetes secret: the first value, existingSecret is the name of the secret, and the second, passwordSecretKey is the key to the secret.

[mkelton]

Thank you very much! Thanks to your help, I now understand how it works. I was able to run it with my password. Another step forward!

However, these Kubernetes clusters feel like rickety structures. It’s almost impossible to uninstall and reinstall the application, even on Linux. The settings get cluttered with leftover configurations that ignore the new ones. Maybe the quality is better when it comes to professional cloud solutions.

[nathan.loding]

@mkelton - it is a better experience in a professional cloud environment, but it’s also true that Kubernetes wasn’t ever built with the intention of doing iterative troubleshooting of deployments one config value at a time. When testing your configuration and trying to find the right settings for your environment, it’s often best to tear the system down and deploy fresh. That’s not possible once you have a production system that needs to maintain data and uptime, but it’s often a faster approach during the initial deployment testing. Once a production system is running, the configuration changes should be minimal and it should mostly be upgrading the images to the latest versions.