[EPIC]: Add Identity about camunda-platform-helm HOT 19 CLOSED

@Zelldon a user can be added per env variables f.e. like here:
https://github.com/camunda-cloud/identity/blob/main/docker-compose-e2e.yml#L37

or here without a name but with the Operate role to access operate:
https://github.com/camunda-cloud/operate/blob/master/config/docker-compose.identity.yml#L26

Note that if Operate should be initialized in Identity, two additional values need to be added as in https://github.com/camunda-cloud/operate/blob/master/config/docker-compose.identity.yml#L24

      KEYCLOAK_INIT_OPERATE_SECRET: the-cake-is-alive
      KEYCLOAK_INIT_OPERATE_ROOT_URL: http://localhost:8080

from camunda-platform-helm.

If I port forward to the identity and open it in the browser it redirects immediately to localhost:18080/ (you can see that URL in the image above). This seems to redirect to Keycloak? I Had to port-forward to Keycloak as well to see the login mask. Is this expected?

Yes this is expected right now as you need access to KeyCloaks web interface, it serves the Login page, but also you might want to login to keycloak to configure LDAP etc.

What would be the credentials here to login? The admin user seem to not work here?

As you are about to login to the Camunda Platform this are our default credentials demo:demo

Is there anything I can do to login via CLI? Or direct http requests and get a cookie ? I want to use that in our integration tests, to verify whether login works and I can access the other services. Does this make sense?

I will check it out, not sure yet

from camunda-platform-helm.

Identity was successful integrated with all services and added to the helm charts

from camunda-platform-helm.

Docker-compose: https://github.com/camunda-cloud/operate/pull/2415/files#diff-b358236a4158adf30757eb495bb0d551609faa7a3a796cac4d8d02d523d608ce

from camunda-platform-helm.

To set the keycloak admin credentials in identity (if it is changed from admin/admin) following env variables are used:

• KEYCLOAK_SETUP_USER
• KEYCLOAK_SETUP_PASSWORD

from camunda-platform-helm.

For reference Operate Identity Integration: https://github.com/camunda-cloud/operate/pull/2415

from camunda-platform-helm.

Keycloak does it similar with their passwords, they create a default secret and mount it into the statefulset:

  containers:
        - name: keycloak
          image: docker.io/bitnami/keycloak:16.1.1-debian-10-r52
          imagePullPolicy: IfNotPresent
          securityContext:
            runAsNonRoot: true
            runAsUser: 1001
          env:
            - name: KUBERNETES_NAMESPACE
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
            - name: BITNAMI_DEBUG
              value: "false"
            - name: KEYCLOAK_ADMIN_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: zell-keycloak
                  key: admin-password
            - name: KEYCLOAK_MANAGEMENT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: zell-keycloak
                  key: management-password
            - name: KEYCLOAK_DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: zell-keycloak-postgresql
                  key: password

\cc @menski

from camunda-platform-helm.

Worth to read https://itnext.io/manage-auto-generated-secrets-in-your-helm-charts-5aee48ba6918

from camunda-platform-helm.

https://artifacthub.io/packages/helm/bitnami/common/1.3.4 is used to generate secrets

See
https://github.com/bitnami/charts/blob/master/bitnami/keycloak/templates/secrets.yaml#L18-L19

AND setting in values file

https://github.com/bitnami/charts/blob/master/bitnami/keycloak/values.yaml#L109-L119

from camunda-platform-helm.

@Zelldon one thing I forgot to ask: is it possible to create file mounts from a remote source? We have a custom keycloak theme that we could add to a github release as f.e. a zip archive.

from camunda-platform-helm.

Hey @dlavrenuek it seems https://github.com/bitnami/charts/tree/master/bitnami/keycloak allows to configure init containers and extraVolumes, might be possible with that. But I think this would be something I would do only after we get it running :D So lower prio for me, maybe also something we can add later?

from camunda-platform-helm.

Just sorting my thoughts, reading along https://github.com/bitnami/charts/tree/master/bitnami/keycloak and https://docs.bitnami.com/kubernetes/apps/keycloak/configuration/manage-passwords/

Current idea:

We create a secret for keycloak (admin password) and for postegress (admin pw), mount that via keycloak.auth.existingSecret and keycloak.postgress.existingSecret. This secret contains default values like admin:admin, which is also mounted into identity.

The user can specify an own secret, which can be mounted than in keycloak, postgress and identity and replaces our default secrets. We will then not deploy own secrets.

Example secret:

existingSecret:
  name: mySecret
  keyMapping:
    admin-password: myPasswordKey
    management-password: myManagementPasswordKey
    database-password: myDatabasePasswordKey
    tls-keystore-password: myTlsKeystorePasswordKey
    tls-truststore-password: myTlsTruststorePasswordKey

https://docs.bitnami.com/kubernetes/apps/keycloak/configuration/manage-passwords/

\cc @menski

from camunda-platform-helm.

Small update:

I run a test where I deployed the following secret:

apiVersion: v1
kind: Secret
metadata:
  name: ccsm-keycloak-secrets
type: Opaque
stringData:
  admin-password: "admin"
  password: "admin"
  management-password: "admin"

This can be seen as our default secret we would deploy in our helm charts, (btw if we see the need this could also be random values). For simplicity with integrating with identity I sticked to the admin:admin thingy.

I run helm install zell-keycloak bitnami/keycloak --dry-run -f values.yaml --debug, to see what the manifests would look like.

The values file looks like this:

## Keycloak authentication parameters
## ref: https://github.com/bitnami/bitnami-docker-keycloak#admin-credentials
##
auth:
  ## @param auth.adminUser Keycloak administrator user
  ##
  adminUser: admin
  ## @param auth.existingSecret An already existing secret containing auth info
  ## e.g:
  ## existingSecret:
  ##   name: mySecret
  ##   keyMapping:
  ##     admin-password: myPasswordKey
  ##     management-password: myManagementPasswordKey
  ##     tls-keystore-password: myTlsKeystorePasswordKey
  ##     tls-truestore-password: myTlsTruestorePasswordKey
  ##
  ##
  existingSecret:
    name: ccsm-keycloak-secrets

postgresql:
  auth:
    existingSecret: "ccsm-keycloak-secrets"

This causes to deploy a keycloak with the following env vars:

...
      containers:
        - name: keycloak
          image: docker.io/bitnami/keycloak:16.1.1-debian-10-r52
          imagePullPolicy: IfNotPresent
          securityContext:
            runAsNonRoot: true
            runAsUser: 1001
          env:
            - name: KUBERNETES_NAMESPACE
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
            - name: BITNAMI_DEBUG
              value: "false"
            - name: KEYCLOAK_ADMIN_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ccsm-keycloak-secrets
                  key: admin-password
            - name: KEYCLOAK_MANAGEMENT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ccsm-keycloak-secrets
                  key: management-password
            - name: KEYCLOAK_DATABASE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ccsm-keycloak-secrets
                  key: password

And postgress also uses our configured secret:

  containers:
        - name: postgresql
          image: docker.io/bitnami/postgresql:14.2.0-debian-10-r35
          imagePullPolicy: "IfNotPresent"
          securityContext:
            runAsUser: 1001
          env:
            - name: BITNAMI_DEBUG
              value: "false"
            - name: POSTGRESQL_PORT_NUMBER
              value: "5432"
            - name: POSTGRESQL_VOLUME_DIR
              value: "/bitnami/postgresql"
            - name: PGDATA
              value: "/bitnami/postgresql/data"
            # Authentication
            - name: POSTGRES_USER
              value: "bn_keycloak"
            - name: POSTGRES_POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ccsm-keycloak-secrets
                  key: postgres-password
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: ccsm-keycloak-secrets
                  key: password
            - name: POSTGRES_DB
              value: "bitnami_keycloak"

This now allows us to deploy the secret per default, and the user could potentially replace it with an own secret. We just need to configure identity similar, that it access the secret.

from camunda-platform-helm.

@Zelldon If it is possible to have all secrets being randomly generated, we should do it. Having default secrets will always lead to security risks because there will be users who forget to update it or just don't know/understand how to do it.

from camunda-platform-helm.

Hey @dlavrenuek and @menski

yesterday I made some good progress, and had a breakthrough 🎉

All services where up and running and seem to connect to each other.

But there came up some questions form me which I would like to clarify, you can have a look at the changes here #251

BTW @dlavrenuek thanks for your input! I removed our default secret and reuse the secrets generated by the keycloak helm chart, which are random generated if not specified.

Questions:

1. If I port forward to the identity and open it in the browser it redirects immediately to localhost:18080/ (you can see that URL in the image above). This seems to redirect to Keycloak? I Had to port-forward to Keycloak as well to see the login mask. Is this expected?
2. What would be the credentials here to login? The admin user seem to not work here?
3. Is there anything I can do to login via CLI? Or direct http requests and get a cookie ? I want to use that in our integration tests, to verify whether login works and I can access the other services. Does this make sense?

Would be really nice if you could check the questions above and maybe also have a small look at the PR #251 , whether the configuration makes sense to you.

from camunda-platform-helm.

One think I saw during manually testing is that identity crashloops until keycloak is available, maybe we can add here a better handling. Like we do in operate/tasklist? @menski @dlavrenuek

from camunda-platform-helm.

Nice thanks @dlavrenuek this helps for the Operate integration I will do after #251 is merged and we have the next release candidate

from camunda-platform-helm.

@Zelldon is it possible to specify Keycloak as a dependency to Identity in a way so Identity is only started after Keycloak did? We do it in docker-compose with depends_on:... but it does not support a readiness probe, so the Identity container is restarted multiple times.

from camunda-platform-helm.

This is not possible in K8s, see also https://stackoverflow.com/a/53059163/2165134

Normally afaik applications retry and support a readiness and liveness check, here we can add a delay

from camunda-platform-helm.