bbakker2
commented
1 month ago Hi @Ben-Sheppard, we ran into the same issue (https://jira.camunda.com/servicedesk/customer/portal/1/SUPPORT-24027). IMHO this is due to both design and documentation issues.
- Design: In a single tenant deployment Operate/Tasklist can cancel or retry jobs without explicit opt-in. Due to "principle of least surprise" I would expect the same when switching to multitenancy.
- Design: Operate and Tasklist already have a Keycloak identities / credentials, 'operate' and 'tasklist'. Why do they share an extra credential 'zeebe' to call zeebe? Sharing credentials is bad security practice, and not needed here anyway.
- Documentation: yes, the page you propose sounds good. It's the one I read and I would have expected instructions there.
Related: are there any other undocumented steps with respect to enabling multitenancy?
Best regards,
Bastiaan
b-byrne
jonathanlukas
Related to: Support
Description
A customer noted that with multi tenancy enabled there were issues where Zeebe was unable to retrieve jobs for a tenant when cancelling or retrying via Operate/Tasklist. The reason for this is due to the Zeebe client that Operate/Tasklist is configured with needs to be provided access to the tenant(s) in question to be able to perform the actions.
Possible solution
I believe that the documentation around this topic could be improved to make it clearer that there needs to be some configuration added to allow the clients to access the tenants correctly. I think a candidate page could be https://docs.camunda.io/docs/next/self-managed/operational-guides/configure-multi-tenancy/