fix(broker): add multitenancy configuration

[nloding]

Description

Add multitenancy variable configuration to the Zeebe Broker. It was previously undocumented, but if you are using an embedded gateway configuration, you need to use the broker settings rather than the gateway settings.

When should this change go live?

• This change is not yet live and should not be merged until {ADD_DATE} (apply hold label or convert to draft PR)?
• There is no urgency with this change.
• This change or page is part of a marketing blog, conference talk, or something else on a schedule.
• This functionality is already available but undocumented.
• This is a bug fix or security concern.

PR Checklist

• I have added changes to the relevant /versioned_docs directory, or they are not for an already released version.
• I have added changes to the main /docs directory (aka /next/), or they are not for future versions.
• My changes require an Engineering review, and I've assigned an engineering manager or tech lead as a reviewer, or my changes do not require an Engineering review.
• My changes require a technical writer review, and I've assigned @christinaausley as a reviewer, or my changes do not require a technical writer review.

[github-actions]

👋 🤖 ✅ Looks like the changes were ported across versions, nice job! 🎉

You can read more about the versioning within our docs in our documentation guidelines.

[nloding]

After pushing this, I realized that the broker configuration guide doesn't have any of the ZEEBE_BROKER_GATEWAY_SECURITY_* variables documented either, which are required to set the identity.baseUrl property required by multi-tenancy ... see these variables here: https://github.com/camunda/camunda-platform/blob/main/docker-compose.yaml#L21-L24C46

[akeller]

@koevskinikola @Ben-Sheppard can we get your input here? This closes the loop on an open community feedback topic @nloding has been working.

See these threads/PRs for more context:

• https://camunda.slack.com/archives/C0555930H7F/p1702658366563479
• fix(self-managed/zeebe): correct MT feature flag #3021

@Ben-Sheppard see @nloding's comment above this one re: identity.baseUrl.

[akeller]

Adding the hold label so we can collaborate and not view this as blocking for the 8.4 release.

[nloding]

I copied/pasted/updated the security.authentication variables from the gateway config to the broker config. There was one value in the gateway config (ZEEBE_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_TYPE) that I am not familiar with and isn't needed for MT, so I left it out. I am unsure if that's a valid variable for the broker config and should be included in the docs? My outstanding questions, which may or may not be within the scope of this PR:

• With the authentication/Identity values in Zeebe being deprecated in 8.4, are my updates to the broker page valid?
• What other variables are missing? :)
• The variables on the gateway page are listed a different order than the broker page; I think they should follow the same order. The broker page is alphabetical, which I think makes sense for long term maintenance. Should we standardize this?

[akeller]

The variables on the gateway page are listed a different order than the broker page; I think they should follow the same order. The broker page is alphabetical, which I think makes sense for long term maintenance. Should we standardize this?

I'm not sure I see an order on either page. The order should match the template on the Zeebe repo.

[koevskinikola]

Hi @akeller @nloding,

Unfortunately, I haven't had a lot of time in the last two weeks to review this PR. I will probably be able to review it properly after 22.01.2024.

If a review is more urgent, then please ask another Zeebe team member to have a look. The changes are more related to the structure of the docs related to the Zeebe config properties rather than multi-tenancy.

From just a quick look at the PR, I can note that the changes make the Broker configuration page look a bit inconsistent since we're only mirroring the Gateway properties related to multi-tenancy. That might be even more confusing to users.

[koevskinikola]

@nloding @akeller I finally managed to review this PR.

In general the text looks good, I'm just worried that it will cause some confusion if we structure it like this. I left some suggestions on how we can avoid that.

[akeller]

Made a few adjustments to this PR.

[nloding]

This looks great! 🚀

Addressed in recent commit.