Version: 8.10 (unreleased)

Configure a multi-namespace deployment

A multi-namespace deployment runs Camunda Hub and Management Identity in a Hub namespace and runs the Orchestration Cluster in another namespace.

This configuration supports Camunda 8.10. Camunda Hub contains Web Modeler and Console. Console isn't a separate deployment in 8.10.

Before you begin

Prepare the following resources:

An external Keycloak instance that both namespaces can reach. The example uses Management Identity to register clients in Keycloak.
Separate public hostnames and TLS certificates for the Hub and orchestration namespaces.
External PostgreSQL databases for Management Identity and Camunda Hub.
A supported secondary storage backend for the Orchestration Cluster and Optimize.
Network policies that permit Domain Name System (DNS) traffic and required cross-namespace service traffic.

The examples use camunda as the release name in both namespaces, hub as the Hub namespace, and orchestration as the orchestration namespace. If you change the release name or namespaces, update every Kubernetes service name.

Use Helm 4 and a chart 15.x version that supports Camunda 8.10. Select a supported version from the Helm chart version matrix, then set it before installation:

export HELM_CHART_VERSION=<15.x-chart-version>

Allow required network traffic

If you enforce NetworkPolicies, allow the following traffic in addition to your database and secondary-storage connections:

Source	Destination	Ports	Purpose
Both namespaces	Cluster DNS	`53/TCP`, `53/UDP`	Resolve cross-namespace service names
Camunda Hub	`camunda-zeebe-gateway.orchestration.svc.cluster.local`	`26500/TCP`, `8080/TCP`	Deploy processes and call the Orchestration Cluster API
Camunda Hub	`camunda-zeebe.orchestration.svc.cluster.local`	`9600/TCP`	Check Orchestration Cluster application readiness
Camunda Hub	`camunda-optimize.orchestration.svc.cluster.local`	`80/TCP`	Check Optimize readiness
Camunda Hub	`camunda-connectors.orchestration.svc.cluster.local`	`8080/TCP`	Check Connectors readiness
Orchestration namespace	`camunda-identity.hub.svc.cluster.local`	`80/TCP`	Use central Management Identity
Both namespaces	Your OIDC provider	Provider HTTPS port	Authenticate users and clients

Restrict policies to the listed workloads and namespaces instead of allowing unrestricted cross-namespace traffic.

Manage secrets across namespaces

Kubernetes Secrets are namespace-scoped. Create the client secrets used by both central Management Identity and a remote workload in both namespaces with identical values.

The following example uses these Secrets:

Secret	Key	Required namespaces	Purpose
`keycloak-admin`	`password`	`hub`	Keycloak administration for Management Identity
`identity-first-user`	`password`	`hub`	Initial Management Identity user
`identity-database`	`password`	`hub`	Management Identity database
`hub-database`	`password`	`hub`	Camunda Hub database
`hub-pusher`	`app-key`, `app-secret`	`hub`	Stable Camunda Hub WebSocket credentials across upgrades
`orchestration-oidc`	`client-secret`	`hub`, `orchestration`	Orchestration OIDC client
`connectors-oidc`	`client-secret`	`hub`, `orchestration`	Connectors OIDC client
`optimize-oidc`	`client-secret`	`hub`, `orchestration`	Optimize OIDC client
`secondary-storage`	`password`	`orchestration`	Elasticsearch password for Orchestration and Optimize
`hub-tls`	`tls.crt`, `tls.key`	`hub`	Hub Ingress TLS
`orchestration-tls`	`tls.crt`, `tls.key`	`orchestration`	Orchestration HTTP Ingress TLS
`orchestration-grpc-tls`	`tls.crt`, `tls.key`	`orchestration`	Orchestration gRPC Ingress TLS

Use an external secret manager to synchronize the values. Don't store production credentials directly in a Helm values file.

Configure the Hub namespace

Create hub-values.yaml. The alwaysRegister values instruct central Management Identity to register clients for workloads deployed by another Helm release. The clusters entry connects Camunda Hub to the remote Orchestration Cluster.

global:
  host: hub.example.com
  ingress:
    enabled: true
    className: nginx
    tls:
      enabled: true
      secretName: hub-tls
  security:
    authentication:
      method: oidc
  identity:
    keycloak:
      url:
        protocol: https
        host: login.example.com
        port: 443
      contextPath: /
      realm: /realms/camunda-platform
      auth:
        adminUser: admin
        secret:
          existingSecret: keycloak-admin
          existingSecretKey: password
    auth:
      enabled: true
      type: KEYCLOAK
      publicIssuerUrl: https://login.example.com/realms/camunda-platform
      issuerBackendUrl: https://login.example.com/realms/camunda-platform
      authUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/auth
      tokenUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/token
      jwksUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/certs
      camundaHub:
        redirectUrl: https://hub.example.com/modeler
      optimize:
        alwaysRegister: true
        redirectUrl: https://orchestration.example.com/optimize
        secret:
          existingSecret: optimize-oidc
          existingSecretKey: client-secret
      orchestration:
        alwaysRegister: true
      connectors:
        alwaysRegister: true

identity:
  enabled: true
  contextPath: /identity
  firstUser:
    secret:
      existingSecret: identity-first-user
      existingSecretKey: password
  externalDatabase:
    enabled: true
    host: identity-postgresql.example.com
    port: 5432
    username: identity
    database: identity
    secret:
      existingSecret: identity-database
      existingSecretKey: password

camundaHub:
  enabled: true
  contextPath: /modeler
  restapi:
    mail:
      fromAddress: noreply@example.com
    externalDatabase:
      url: jdbc:postgresql://hub-postgresql.example.com:5432/hub
      username: hub
      secret:
        existingSecret: hub-database
        existingSecretKey: password
    pusher:
      client:
        secret:
          existingSecret: hub-pusher
          existingSecretKey: app-key
      secret:
        existingSecret: hub-pusher
        existingSecretKey: app-secret
    clusters:
      - id: orchestration
        name: Orchestration
        # Match this to the Camunda version deployed by your selected chart.
        version: "8.10.x"
        authentication: BEARER_TOKEN
        url:
          grpc: grpc://camunda-zeebe-gateway.orchestration.svc.cluster.local:26500
          rest: http://camunda-zeebe-gateway.orchestration.svc.cluster.local:8080
          web-app: https://orchestration.example.com/orchestration
        components:
          - name: Optimize
            type: optimize
            version: "8.10.x"
            urls:
              webapp: https://orchestration.example.com/optimize
              readiness: http://camunda-optimize.orchestration.svc.cluster.local:80/optimize/api/readyz
          - name: Connectors
            type: connectors
            version: "8.10.x"
            urls:
              rest: http://camunda-connectors.orchestration.svc.cluster.local:8080/connectors
              readiness: http://camunda-connectors.orchestration.svc.cluster.local:8080/connectors/actuator/health/readiness
          - name: Operate
            type: operate
            version: "8.10.x"
            urls:
              webapp: https://orchestration.example.com/orchestration/operate
              readiness: http://camunda-zeebe.orchestration.svc.cluster.local:9600/orchestration/actuator/health/readiness
          - name: Tasklist
            type: tasklist
            version: "8.10.x"
            urls:
              webapp: https://orchestration.example.com/orchestration/tasklist
              readiness: http://camunda-zeebe.orchestration.svc.cluster.local:9600/orchestration/actuator/health/readiness
          - name: Orchestration Admin
            type: admin
            version: "8.10.x"
            urls:
              webapp: https://orchestration.example.com/orchestration/admin
              readiness: http://camunda-zeebe.orchestration.svc.cluster.local:9600/orchestration/actuator/health/readiness
          - name: Orchestration Cluster
            type: orchestration
            version: "8.10.x"
            urls:
              grpc: grpc://camunda-zeebe-gateway.orchestration.svc.cluster.local:26500
              rest: http://camunda-zeebe-gateway.orchestration.svc.cluster.local:8080
              readiness: http://camunda-zeebe.orchestration.svc.cluster.local:9600/orchestration/actuator/health/readiness

orchestration:
  enabled: false
  security:
    authentication:
      oidc:
        redirectUrl: https://orchestration.example.com/orchestration
        secret:
          existingSecret: orchestration-oidc
          existingSecretKey: client-secret

connectors:
  enabled: false
  security:
    authentication:
      oidc:
        secret:
          existingSecret: connectors-oidc
          existingSecretKey: client-secret

optimize:
  enabled: false

Adapt the Keycloak endpoints and client configuration for your environment. See external Keycloak. If you use another OIDC provider, create and manage the clients in that provider instead of using alwaysRegister; see external OIDC provider.

Install the Hub release:

helm install camunda camunda/camunda-platform \
  --version "$HELM_CHART_VERSION" \
  --namespace hub \
  --create-namespace \
  --values hub-values.yaml

Configure the orchestration namespace

Create orchestration-values.yaml. The Management Identity URL uses the Hub release's internal Kubernetes service. The OIDC client IDs and secrets must match the clients registered by Management Identity.

global:
  host: orchestration.example.com
  ingress:
    enabled: true
    className: nginx
    tls:
      enabled: true
      secretName: orchestration-tls
  security:
    authentication:
      method: oidc
  identity:
    service:
      url: http://camunda-identity.hub.svc.cluster.local:80/identity
    auth:
      enabled: true
      type: KEYCLOAK
      publicIssuerUrl: https://login.example.com/realms/camunda-platform
      issuerBackendUrl: https://login.example.com/realms/camunda-platform
      authUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/auth
      tokenUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/token
      jwksUrl: https://login.example.com/realms/camunda-platform/protocol/openid-connect/certs
      optimize:
        redirectUrl: https://orchestration.example.com/optimize
        secret:
          existingSecret: optimize-oidc
          existingSecretKey: client-secret

identity:
  enabled: false

camundaHub:
  enabled: false

orchestration:
  enabled: true
  contextPath: /orchestration
  data:
    secondaryStorage:
      type: elasticsearch
      elasticsearch:
        url: https://elasticsearch.example.com:9200
        auth:
          username: camunda
          secret:
            existingSecret: secondary-storage
            existingSecretKey: password
  ingress:
    grpc:
      enabled: true
      className: nginx
      host: zeebe.orchestration.example.com
      tls:
        enabled: true
        secretName: orchestration-grpc-tls
  security:
    authentication:
      oidc:
        redirectUrl: https://orchestration.example.com/orchestration
        secret:
          existingSecret: orchestration-oidc
          existingSecretKey: client-secret

connectors:
  enabled: true
  security:
    authentication:
      oidc:
        secret:
          existingSecret: connectors-oidc
          existingSecretKey: client-secret

optimize:
  enabled: true
  contextPath: /optimize
  database:
    elasticsearch:
      enabled: true
      external: true
      url:
        protocol: https
        host: elasticsearch.example.com
        port: 9200
      auth:
        username: camunda
        secret:
          existingSecret: secondary-storage
          existingSecretKey: password

This example uses Elasticsearch as shared secondary storage. Enabling Optimize automatically enables the Legacy Zeebe Exporter, which writes the records Optimize reads. The Orchestration Cluster and Optimize settings must point to the same backend, and the secondary-storage Secret must exist in the orchestration namespace.

For OpenSearch, relational database, TLS, and custom index-prefix configuration, see database configuration. If you customize the Legacy Zeebe Exporter prefix, configure Optimize to read the same prefix as described in configure Elasticsearch and OpenSearch index prefixes.

Install the orchestration release after the Hub release is ready:

helm install camunda camunda/camunda-platform \
  --version "$HELM_CHART_VERSION" \
  --namespace orchestration \
  --create-namespace \
  --values orchestration-values.yaml

Add another Orchestration Cluster

The alwaysRegister values register one set of Orchestration Cluster, Connectors, and Optimize clients. They don't create a separate client set for every orchestration namespace.

To add another Orchestration Cluster, provision its clients and redirect URLs directly in your OIDC provider. Configure the additional Helm release with those client IDs and secrets, then add its endpoint to camundaHub.restapi.clusters. Use unique credentials when you need security isolation between clusters.

Before you begin​

Allow required network traffic​

Manage secrets across namespaces​

Configure the Hub namespace​

Configure the orchestration namespace​

Add another Orchestration Cluster​