How to change the default idm user via the Helm Chart

Flowable Engine
1

When using the helm chart, how do we change the default username/password?

We tried passing the java opts to the helm install command like this:

--set idm.javaOpts="flowable.common.app.idm-admin.user=admin,flowable.common.app.idm-admin.password=nottest"

This caused a login loop for modeler, workflow, and admin where it entering a username/password just redisplayed the login. Logging in to adm still works but with the old admin/test combo completely ignoring the new password.

2

Hi.

Are you using the published Flowable (6.5.0) Helm chart?
Or are you using the current master version?

Regards,

Yvo

3

The published 6.5.0 chart

4

The properties for changing / setting the default admin account are not exposed in the 6.5.0 Helm template.
This is added in the chart of the upcoming release.
It should be possible to use the JAVA_OPTS for injecting them. However the JAVA_OPTS are not used in the ENTRY_POINT of the used Docker images.
I will fix this.

For the 6.5.0 release I would suggest not using the Helm chart but modifying the Kubernetes config maps.
Modify in the ‘apps’ configs (modeler / task etc) ; used for authentication

 FLOWABLE_COMMON_APP_IDM-ADMIN_USER: <userid>
 FLOWABLE_COMMON_APP_IDM-ADMIN_PASSWORD: <test>

Add in IDM config ;used for the user creation

FLOWABLE_IDM_APP_ADMIN_USER-ID=<userid>
FLOWABLE_IDM_APP_ADMIN_PASSWORD=<password>

Hope this helps.

Yvo

5

We tried this for all of the currently deployed components (admin, idm, modeler, task) and in each case the behavior was:

  1. changes to the app config values for authentication (*_COMMON_*) caused three of the components - admin, modeler, and task - to continually redirect back to the login screen (perpetual login loop). Additionally, this change had no effect on the admin user the database i.e. the username and password remained the same as before (“admin”/“test”).
    While troubleshooting, we also tried a manual update to the password (in ACT_ID_USER), and then noticed that for approximately 2 minutes the same three components were accessible with the new credentials, then all started returning 503 errors and were no longer available.

  2. changes to the user creation values in IDM config caused the application to return 503 errors until the password was manually reverted in the database (in ACT_ID_USER)
    Example values which caused this behavior:
    FLOWABLE_IDM_APP_ADMIN_USER-ID: admin
    FLOWABLE_IDM_APP_ADMIN_PASSWORD: nottest
    The password does not get changed in the database; however, the password does get repopulated if it is manually deleted (deleting the credentials row), with the value of “nottest”, and accompanied with more 503 errors:

    flowable-database-oddity
    flowable-database-oddity742×20 8.66 KB

Finally, we tried to change the admin password through the IDM UI, coupled with changing the (*_COMMON_*) variables, and this also resulted in 503 errors. This did update the password in the database; however, the only way to restore service was to return the database password to the default value (“test”).

6

@yvo any other suggestions or avenues to explore here based on the information we shared last week? This is not yet a blocker but does present a security/durability concern going forward. Thank you

7

For anyone still on the v6.5 helm chart, experiencing recurring 503 errors, this could be due to the hard coded authorization values in the readiness and liveness probes for each service

    readinessProbe:
      httpGet:
        path: /actuator/health
        port: 8888
        httpHeaders:
        - name: Authorization
          value: Basic YWRtaW46dGVzdA==
      initialDelaySeconds: 60
      timeoutSeconds: 5
    livenessProbe:
      httpGet:
        path: /actuator/health
        port: 8888
        httpHeaders:
        - name: Authorization
          value: Basic YWRtaW46dGVzdA==

I would recommend changing those base64 encoded values to the following

{{-  printf "%s:%s" "username" "password" | b64enc }}
1 Like