Camunda 8.8 via Helm on EKS - Permissions Errors using Orchestration Cluster API

Camunda 8 Topics Discussion & Questions
1

Hello. I am currently building an environment to trial Camunda 8.8 by following this guide to deploy it on AWS EKS via Helm:

My setup includes:

  • Orchestration Cluster
  • Connectors
  • Management Identity
  • Optimize
  • Console

The options I’m using include “With Domain” and “IRSA”. For authentication I am using Keycloak included in the Helm chart, with an Aurora PostgreSQL DB managed externally.

I’ve been able to deploy the environment successfully and am currently up to the section “Verify connectivity to Camunda 8”, and getting the following error when deploying my BPMN diagram from Camunda Desktop Modeler (v5.39.0):

Command 'CREATE' rejected with code 'FORBIDDEN': Insufficient permissions to perform operation 'CREATE' on resource 'RESOURCE' [ deploy-error ]

The doco says to use zeebe-api for the audience, but I have also tried orchestration-api and that gives the same error. I tried following the “REST API” instructions on the docs page and could get /v2/topology to work but I get the same error as above with v2/deployments.

I thought that maybe with the split of Identity and ManagementIdentity in 8.8 I need to perform additional steps to grant access within Identity, so went to the Identity web UI, to Roles > Admin > Clients and tried adding the Client IDs for my test application and the included orchestration client and still got the error.

Has anyone else been able to follow this guide and get it working on the 8.8 release?

Thanks and regards.

2

Hi @scott.brady,

This is a common issue with Camunda 8.8 deployments, particularly related to the Identity/ManagementIdentity split and OAuth audience configuration. The FORBIDDEN error you’re experiencing is typically caused by a mismatch between the OAuth audience configured in your deployment and what’s expected by the orchestration cluster.

Root Cause

In Camunda 8.8, the orchestration cluster (Zeebe) uses a specific audience for authentication. The most common causes of your error are:

  1. Audience Mismatch: Your Desktop Modeler and REST API calls are using zeebe-api as the audience, but your orchestration cluster might be configured to expect orchestration-api (or vice versa).

  2. Identity Permissions Database: The permissions in your Identity database might still reference the old audience while your cluster expects a different one.

Solution Steps

1. Check Your Orchestration Cluster Audience Configuration

First, verify what audience your orchestration cluster is configured to use. In your Helm values, look for:

orchestration:
  security:
    authentication:
      oidc:
        audience: orchestration-api  # This is the default in 8.8

2. Update Desktop Modeler Configuration

In your Desktop Modeler deployment dialog, ensure you’re using the same audience as configured in your orchestration cluster. If your cluster uses orchestration-api, then use that instead of zeebe-api.

3. Update Identity Permissions Database

If your orchestration cluster expects orchestration-api but your Identity database permissions still reference zeebe-api, you need to update the permissions table:

UPDATE public.permissions
SET audience = 'orchestration-api'
WHERE audience = 'zeebe-api';

4. Verify Client Configuration in Identity

Since you mentioned adding client IDs to the Admin role, ensure that:

  • The client you’re using for deployment has the correct permissions
  • The client is configured with the correct audience
  • The user/application has the necessary roles assigned

5. Check Resource Permissions (if enabled)

If you have RESOURCE_PERMISSIONS_ENABLED=true in your Identity configuration, you might need to either:

  • Assign specific resource permissions to your user/client, or
  • Temporarily disable resource permissions to test:
identity:
  env:
    - name: RESOURCE_PERMISSIONS_ENABLED
      value: "false"

Debugging Steps

  1. Check Identity logs for more specific error messages about the authentication failure
  2. Verify the token you’re getting contains the correct audience claim
  3. Test with REST API using the same audience as your cluster configuration

Quick Test

Try using orchestration-api as the audience in both your Desktop Modeler and REST API calls, as this is the default for Camunda 8.8 orchestration clusters.

Let me know what audience your orchestration cluster is configured to use and whether updating the audience resolves the issue!

References:

3

Thanks @zee-bot .

I had already tried with the audience set to both zeebe-api and orchestration-api as I mentioned in my original post:

The doco says to use zeebe-api for the audience, but I have also tried orchestration-api and that gives the same error.

I have not overridden the value of orchestration.security.authentication.oidc.audience in the Helm chart so it should be using the chart default of orchestration-api .

I have also tried both Desktop Modeler and the v2/deployments REST API endpoint with the same error, as I mentioned in my original post.

As for the Identity Permissions Database, this is a brand new installation of Camunda 8.8 using the Helm chart with a new empty PostgreSQL database. So I am not upgrading from an existing 8.7 or earlier using the same database. Are you saying that even on a new clean 8.8 installation, it could still be using the wrong audience in the DB permissions?

My main question is whether anyone else has been able to create a new clean Camunda 8.8 installation following the EKS documentation and got the permissions to work because I suspect it might be missing some steps, but I can’t figure out which steps they might be as I’m not familiar enough with the changes in splitting Identity from Management Identity in 8.8. Can a Camunda team member please confirm the docs have been validated including BPMN deployment and process instance start permissions? Thanks.

4

Thanks for the clarification @scott.brady! You’re absolutely right - you’ve already tried the standard audience troubleshooting steps, and since this is a fresh 8.8 installation, the typical upgrade-related issues shouldn’t apply.

Based on your experience and the fact that you’re questioning whether the EKS documentation has been fully validated for the 8.8 Identity/ManagementIdentity split, this sounds like it could be a documentation gap or a configuration issue specific to the new architecture.

The key insight from the knowledge base is that in Camunda 8.8’s fresh installations, no default deployment permissions are automatically granted to users or clients in the Orchestration Cluster Identity - they must be explicitly assigned. However, the EKS documentation may not clearly outline these required permission assignment steps.

Since you’re asking for validation from a Camunda team member about whether the documentation has been properly tested for BPMN deployment and process instance permissions, I’m going to escalate this to a Camunda expert who can:

  1. Validate the completeness of the EKS documentation for 8.8
  2. Provide the specific missing steps for permission assignment in the Orchestration Cluster Identity
  3. Confirm whether there are any known issues with the 8.8 EKS deployment guide

A Camunda expert will follow up with you shortly to help resolve this issue and ensure the documentation is accurate and complete.

Thanks for bringing this to our attention - your feedback helps improve the documentation for everyone!

5

Hi @scott.brady,

Thank you very much for your detailed report — it helped us identify a few documentation gaps regarding the Camunda 8.8 Helm setup on EKS.

You’re absolutely right — a few key points were missing or unclear in the previous version of the guide:

  1. Audience / scope — In 8.8, the correct audience is now orchestration-api (no longer zeebe-api).

  2. OIDC admin mapping — Since we now use OIDC with a dedicated admin user, it needs to be explicitly mapped to the cluster’s Identity service. You can see the configuration example here:
    :backhand_index_pointing_right: values-domain.yml#L132

  3. Application role assignment — We’ve added additional setup steps for linking the application to a role in the Orchestration Cluster Identity.
    The updated documentation (currently being deployed) can be previewed here:
    :backhand_index_pointing_right: Preview documentation link

The new section includes the following steps:

  • Navigate to the Orchestration Cluster Identity at https://${DOMAIN_NAME}/identity and log in with the admin user (defined in identity.firstUser).

  • Go to Roles, select or create a role (e.g. Admin).

  • Under the Clients tab, click Assign client.

  • Enter the client ID of your Management Identity application (e.g. test) and click Assign client.

This operation links the OIDC client to the role’s permissions in the Orchestration Cluster, granting the required access to deploy and interact with workflows.

Thanks again for catching this and helping us improve the documentation! :folded_hands:

— The Camunda InfraEx Team

6

Thanks for your reply @leiicamundi and for updating the documentation.

I ran through the docs to set up my environment again and this time I was able to get it working. Thank you very much!

Additional steps I included this time on top of the doc updates:

1 Like
7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.