I have started the camunda-platform docker compose environment. Then I went to Keycloak and changed the super-user password. After a restart of the compose (pushing the stop and play button in Docker Desktop) Identity didn’t start.
OK, you missed the important lines in your reference:
- name: KEYCLOAK_SETUP_PASSWORD
{{- if and .Values.keycloak.auth.existingSecret (not (typeIs "string" .Values.keycloak.auth.existingSecret)) }}
valueFrom:
secretKeyRef:
{{- /*
Helper: https://github.com/bitnami/charts/blob/master/bitnami/common/templates/_secrets.tpl
Usage in keycloak secrets https://github.com/bitnami/charts/blob/master/bitnami/keycloak/templates/secrets.yaml
and in statefulset https://github.com/bitnami/charts/blob/master/bitnami/keycloak/templates/statefulset.yaml
*/}}
name: {{ include "common.secrets.name" (dict "existingSecret" .Values.keycloak.auth.existingSecret "context" $) }}
key: admin-password
{{- else }}
valueFrom:
secretKeyRef:
{{- /*
https://github.com/bitnami/charts/blob/master/bitnami/common/templates/_names.tpl
*/}}
name: {{ include "common.names.dependency.fullname" (dict "chartName" "keycloak" "chartValues" .Values.keycloak "context" $) }}
key: admin-password
{{- end }}
But the variables KEYCLOAK_SETUP_USER and KEYCLOAK_SETUP_PASSWORD are not mentioned in the docs: Configuration variables | Camunda Platform 8. So they didn’t exist for a common user.
And you are not aware about a required change of the value.
we recommend using the helm charts, where Keycloak is included and the admin credentials are randomly generated for security reason. If you want to configure it manually, it is also possible. Here is a relevant part from our configuration with defaults
Yes, it would be helpful to describe the magic connection between Identity and Keycloak it the documentation.
Right now I have no experience with Keycloak and how companies configure it. But these questions pop up in my consultant brain:
Which features of Keycloak are used by Identity?
How can I use my already installed and configured Keycloak in Identity? Does it make sense to use it or is it better to use a keycloak-to-keycloak configuration to reuse all my users and groups?
If I use Keycloak with a random password, is it safe for production? What about a password change policy (change the password each 30 days)? How can I apply it?
If these questions could be somehow addressed in the docs, it would be nice as well.
I will try to give detailed. And of course we are constantly working on improving our docs, so any suggestions are welcome.
Identity uses the admin credentials to authenticate with the Keycloak Admin API. This is required to initialize a new realm for Camunda applications. During initialization there will be applications, roles and mappers created. The Identity UI provides the functionality to manage (create, edit, delete) applications, resource servers, permissions & roles and the possibility to assign permissions to an application (for m2m communication) and roles to a user (f.e. to grant access to Operate, Tasklist, Optimize or Identity). It is possible to configure C8 with an existing Keycloak which, at the moment requires setting admin credentials in Identity (for reasons described above)
At the moment we only support a setup with a Keycloak instance provided by our Helm charts. Using an external Keycloak is possible with preconditions described above. Technically it is possible to use any instance of Keycloak if the required data is added manually (applications, roles, mappers) but this is not something I would advice because we plan to support configuring an existing Keycloak (and realm) in the near future.
It is possible to configure an existing Keycloak as an OIDC provider and use role/scope to role mapping. Afaik mapping by groups is only possible with LDAP. I can not answer what is better, for this purpose I would rather ask the question what do you (as a Camunda C8 user or a client) want to archive and what is your current setup, first?
It should be as safe as setting a password manually. May be @Zelldon can answer the question with some data on how long the generated secret is and what characters are used for it to determine the number of different password. If there are requirements like that the password are changed every x days, this can be implemented by manually setting a password instead of using the default randomly generated ones.
I hope that it provides some deeper technical insights.
I left it out on purpose since the helm templating is not really useful.